gtest as a DLL

[pod...@gmail.com]

I need to compile gtest as a DLL. There is no dllexport in current
version so it's impossible to link it with my executable.

Does anyone made the changes to compile it as a DLL?

[Vlad Losev]

At Google we only use gtest in static libraries and don't have projects to build DLLs. We may end up having DLL builds, but we have a lot of other stuff on our hands now, and may not get around to do it soon. :-(

But if you absolutely have to build gtest as a DLL, an easier way to do it is to add a module definition file to the gtest project and use it to export all the symbols that the linker reports missing. Let us know if you succeed in that and feel free to contribute back to the project. :-)

Regards,
Vlad

[podidoo]

We may work on building gtest as a DLL.

Is there a special reason why you prefer using a .def file to export
symbols?

Are you against a macro to define dllexport before every symbol we
want to export?
Something like:
#ifdef GTEST_EXPORTS
#define GTEST_API __declspec(dllexport)
#else
...



On 18 juin, 04:46, Vlad Losev <vladlo...@gmail.com> wrote:

> On Tue, Jun 16, 2009 at 3:02 AM, podi...@gmail.com <podi...@gmail.com>wrote:
>
>
>
> > I need to compile gtest as a DLL. There is no dllexport in current
> > version so it's impossible to link it with my executable.
>
> > Does anyone made the changes to compile it as a DLL?
>
> At Google we only use gtest in static libraries and don't have projects to
> build DLLs. We may end up having DLL builds, but we have a lot of other
> stuff on our hands now, and may not get around to do it soon. :-(
>
> But if you absolutely have to build gtest as a DLL, an easier way to do it
> is to add a module definition

> file<http://msdn.microsoft.com/en-us/library/28d6s79h%28VS.80%29.aspx>to

[Zhanyong Wan (λx.x x)]

On Wed, Jun 24, 2009 at 6:26 AM, podidoo<pod...@gmail.com> wrote:
>
>
> We may work on building gtest as a DLL.
>
> Is there a special reason why you prefer using a .def file to export
> symbols?
>
> Are you against a macro to define dllexport before every symbol we
> want to export?
> Something like:
> #ifdef GTEST_EXPORTS
>    #define GTEST_API __declspec(dllexport)
> #else
>    ...

Most people don't care about using gtest as a DLL. For them, we don't
want to clutter the source code with lots of GTEST_API macros.

If possible, I'd like to avoid having to maintain a DLL API. What's
the benefit you are looking after by building gtest as a DLL? If it's
memory, how much memory do you estimate you can save by going DLL?
Thanks,

>
>
> On 18 juin, 04:46, Vlad Losev <vladlo...@gmail.com> wrote:
>> On Tue, Jun 16, 2009 at 3:02 AM, podi...@gmail.com <podi...@gmail.com>wrote:
>>
>>
>>
>> > I need to compile gtest as a DLL. There is no dllexport in current
>> > version so it's impossible to link it with my executable.
>>
>> > Does anyone made the changes to compile it as a DLL?
>>
>> At Google we only use gtest in static libraries and don't have projects to
>> build DLLs. We may end up having DLL builds, but we have a lot of other
>> stuff on our hands now, and may not get around to do it soon. :-(
>>
>> But if you absolutely have to build gtest as a DLL, an easier way to do it
>> is to add a module definition
>> file<http://msdn.microsoft.com/en-us/library/28d6s79h%28VS.80%29.aspx>to
>> the gtest project and use it to export all the symbols that the linker
>> reports missing. Let us know if you succeed in that and feel free to
>> contribute back to the project. :-)
>>
>> Regards,
>> Vlad
>

--
Zhanyong

[Zhanyong Wan (λx.x x)]

+ the discussion group

2009/11/13 Lenny Primak <lenny...@gmail.com>:
> In our environment, we have an issue that absolutely requires google
> test
> (or any other 3rd party library) to be a DLL.  Some of our 3rd party
> libraries
> are DLLs, which requires MS RT libraries to be DLLs.  When that
> happens,
> linking google test statically results in multiply defined symbol
> errors,
> which requires google test to be DLL if more than one dependency
> is using google test.
> I can't believe no one ran into this problem before.  This happens
> is google test is being used in any sort of pervasive manner.
> I hate windows macros (windows in general) as much as the next guy
> but the DLL build is a necessity in that environment.
>
> On Jun 24, 11:35 am, Zhanyong Wan (λx.x x) <w...@google.com> wrote:

--
Zhanyong

[Lenny Primak]

In our environment, we have an issue that absolutely requires google
test
(or any other 3rd party library) to be a DLL. Some of our 3rd party
libraries
are DLLs, which requires MS RT libraries to be DLLs. When that
happens,
linking google test statically results in multiply defined symbol
errors,
which requires google test to be DLL if more than one dependency
is using google test.
I can't believe no one ran into this problem before. This happens
is google test is being used in any sort of pervasive manner.
I hate windows macros (windows in general) as much as the next guy
but the DLL build is a necessity in that environment.

On Nov 13, 1:39 pm, Zhanyong Wan (λx.x x) <w...@google.com> wrote:
> + the discussion group

[Lenny Primak]

What is the Google Test's team's preferred/tested way
of building on Windows? I'd like to know so that I can test
the build properly when making the patch for the DLL build.

Thanks

[Zhanyong Wan (λx.x x)]

Hi Lenny,

On Tue, Nov 17, 2009 at 12:35 PM, Lenny Primak <lenny...@gmail.com> wrote:
> What is the Google Test's team's preferred/tested way
> of building on Windows?  I'd like to know so that I can test
> the build properly when making the patch for the DLL build.

If you have scons installed, you may try to build using the scripts in
gtest's scons/ directory. Otherwise you can build using Visual Studio
following the instructions in README. Thanks,

--
Zhanyong

[Lenny Primak]

I have uploaded the patch today.
Please, in the future, when adding new classes/functions/variables
that are meant to be accessed by client apps, put
GOOGLE_TEST_API in front of it.
Thank you.

On Nov 17, 4:03 pm, Zhanyong Wan (λx.x x) <w...@google.com> wrote:
> Hi Lenny,
>

[Zhanyong Wan (λx.x x)]

Given that dllexport makes the code ugly ugly, and a .def file is hard
to create, I'd like to revisit whether it's really necessary to build
gtest as a DLL.

2009/11/13 Lenny Primak <lenny...@gmail.com>:

> In our environment, we have an issue that absolutely requires google
> test
> (or any other 3rd party library) to be a DLL.  Some of our 3rd party
> libraries
> are DLLs, which requires MS RT libraries to be DLLs.  When that
> happens,
> linking google test statically results in multiply defined symbol
> errors,
> which requires google test to be DLL if more than one dependency
> is using google test.

My understanding is that your configuration is like this (=> means
"depends on"):

3rd_party.dll => msrt.dll
production.dll => 3rd_party.dll
gtest.dll => msrt.dll
test1.dll => gtest.dll, production.dll
test2.dll => gtest.dll, production.dll
test.exe => test1.dll, test2.dll

Is this correct? If so, why do you need to put your tests in DLLs?

You can build gtest as a static lib that uses MS RT DLLs. Then would
the following work for you?

3rd_party.dll => msrt.dll
production.dll => 3rd_party.dll
gtest.lib => msrt.dll
test1.lib => gtest.lib, production.dll
test2.lib => gtest.lib, production.dll
test.exe => test1.lib, test2.lib

Sorry for being dense, Lenny. I haven't done Windows programming for
a long time and have forgotten many details of how DLL works (or I
never understood it to begin with :-)).

> I can't believe no one ran into this problem before.  This happens
> is google test is being used in any sort of pervasive manner.
> I hate windows macros (windows in general) as much as the next guy
> but the DLL build is a necessity in that environment.
>

> On Jun 24, 11:35 am, Zhanyong Wan (λx.x x) <w...@google.com> wrote:

--
Zhanyong

[Lenny Primak]

Zhanyong,

When you use your proposed configuration,
when building test1.lib, test2.lib and test.exe,
you will get multiply defined symbols from msrt, and gtest.dll
in the build. MS tools are just weird/inflexible.
Also, you cannot mix MSRT DLL and MSRT lib configurations in the
same codebase. This will lead to crashes and runtime errors.

Believe me if there was any other way I would prefer it,
but in order to support the MS platform, the DLL
thing has to happen.

On Dec 3, 9:41 am, Zhanyong Wan (λx.x x) <w...@google.com> wrote:
> Given that dllexport makes the code ugly ugly, and a .def file is hard
> to create, I'd like to revisit whether it's really necessary to build
> gtest as a DLL.
>

> 2009/11/13 Lenny Primak <lennypri...@gmail.com>:

[Zhanyong Wan (λx.x x)]

On Thu, Dec 3, 2009 at 7:11 AM, Lenny Primak <lenny...@gmail.com> wrote:
> Zhanyong,
>
> When you use your proposed configuration,
> when building test1.lib, test2.lib and test.exe,
> you will get multiply defined symbols from msrt, and gtest.dll

I don't understand. There is no gtest.dll in my proposal. I said
gtest.lib, which is a static lib that uses msrt.dll.

> in the build.  MS tools are just weird/inflexible.
> Also, you cannot mix MSRT DLL and MSRT lib configurations in the
> same codebase.

I didn't suggest to mix msrt.dll and msrt.lib. I said to use msrt.dll
everywhere.

> This will lead to crashes and runtime errors.
>
> Believe me if there was any other way I would prefer it,
> but in order to support the MS platform, the DLL
> thing has to happen.

This may be the case, but I still want to understand why. :-)

--
Zhanyong

[Lenny Primak]

Zhanyong,

I literally spent a month trying to get it to work without having
it be a .dll. I did not succeed. I can't remember all the
gyrations I went through during this process.
Anyway, let me try to explain this...

First, there is no such thing as gtest.lib => msrt.dll.
Just like on unix, a .lib is an archive of objects, with no
dependencies.

Here's the confiration.
myLibOne => thirdPartyOne.dll, (the only thing available)
myLibTwo => thirdPartyOne.dll
myTestsOne => gtest.lib, thirdPartyOne.dll
myTestsTwo => gtest.lib, thirdPartyOne.dll
myExeWithTests.exe => myLibOne, oyLibTwo, myTestsOne, myTestsTwo,
gtest.lib, thirdPartyOne.dll, msrt.dll

myExeWithTests.exe fails to link because
it brings in chunks of msrt and gtest that are brought in multiple
copies of gtest.lib
by the two test libraries.

It's hard to explain all the details because
the MS DLL/library linking is not straight forward and 'weird'.

When you link with a .dll, you actually link with an 'import
library' (.lib)
which has a mix of static, external symbols which are 'brought into
the dependency',
and 'import' symbols which refer to a piece of code/data in the DLL
itself.

So, a DLL link is actually a mix of static and dynamic linking.

The one takeaway from working with MS tools that I took away
that a lot of things that should theoretically work, make sense to
work,
in the MS environment just don't for one stupid reason or another.
This is just the way it is in the MS world and it just has
to be worked around.

On Dec 3, 10:22 am, Zhanyong Wan (λx.x x) <w...@google.com> wrote:

[Zhanyong Wan (λx.x x)]

Thanks for the clarification Lenny. I'll do some experiments myself
to see where the problem is. Some quick comments below.

On Thu, Dec 3, 2009 at 8:17 AM, Lenny Primak <lenny...@gmail.com> wrote:
> Zhanyong,
>
> I literally spent a month trying to get it to work without having
> it be a .dll.  I did not succeed.  I can't remember all the
> gyrations I went through during this process.
> Anyway, let me try to explain this...
>
> First, there is no such thing as gtest.lib => msrt.dll.
> Just like on unix, a .lib is an archive of objects, with no
> dependencies.

By "=>" I don't mean static linking or resolved dependency. gtest
uses stuff from MS RT, so it depends on the latter. How the
dependency is implemented by the linker is a different question. By
"gtest.lib => msrt.dll" I mean that when you build gtest.lib, you
specify that you want to use msrt as a DLL.

> Here's the confiration.
> myLibOne => thirdPartyOne.dll,   (the only thing available)
> myLibTwo => thirdPartyOne.dll
> myTestsOne => gtest.lib, thirdPartyOne.dll
> myTestsTwo => gtest.lib, thirdPartyOne.dll
> myExeWithTests.exe => myLibOne, oyLibTwo, myTestsOne, myTestsTwo,
> gtest.lib, thirdPartyOne.dll, msrt.dll

Are myLibOne, myLibTwo, myTestsOne, myTestsTwo all static libs?

--
Zhanyong

[Lenny Primak]

Here's the use cases:
- Want to make google test pervasive in the code,
to spearhead test-driven development, better code, etc.
- google test a 'core' library (lots of things depend on it)
- ability to bake tests into the library being tested,
thus promoting test visibility, i.e. when i change the library,
i want to 'see' the tests so i remember to update them
- modularity, i.e. lots of small libraries with minimum functionality
that do one thing and one thing well

This means:
- using google test everywhere - don't even want to think whether to
include <gtest.h> or not - just do it

To answer your question... all myLibXXX can be either static or
dynamic (it doesn't matter)
and not effect that if google test is NOT a DLL, this will result in
multiply-defined symbols.
I tried any number of combinations.

I am not the only one running into this problem. I am just the
only one trying to do something about it :)

Anyway, these macros are not that bad. If you take a look
at any open source project that's portable to windows
(core libraries, like google test) they all have
these macros in the code. It's just a necessity if you want
gtest to work on windows in a complete, as opposed to half-baked)
manner

On Dec 3, 11:30 am, Zhanyong Wan (λx.x x) <w...@google.com> wrote:
> Thanks for the clarification Lenny.  I'll do some experiments myself
> to see where the problem is.  Some quick comments below.
>

[Vlad Losev]

Hi Lenny,

On Thu, Dec 3, 2009 at 4:17 PM, Lenny Primak <lenny...@gmail.com> wrote:

Zhanyong,

I literally spent a month trying to get it to work without having
it be a .dll.  I did not succeed.  I can't remember all the
gyrations I went through during this process.
Anyway, let me try to explain this...

First, there is no such thing as gtest.lib => msrt.dll.
Just like on unix, a .lib is an archive of objects, with no
dependencies.

Here's the confiration.
myLibOne => thirdPartyOne.dll,   (the only thing available)
myLibTwo => thirdPartyOne.dll
myTestsOne => gtest.lib, thirdPartyOne.dll
myTestsTwo => gtest.lib, thirdPartyOne.dll
myExeWithTests.exe => myLibOne, oyLibTwo, myTestsOne, myTestsTwo,
gtest.lib, thirdPartyOne.dll, msrt.dll

I see now why you need the DLL support. At  Google, we write tests in multiple executables rather than in multiple DLLs. Those executables are then run together by a test runner. Thus we never needed dynamic libraries.

Regards,

Vlad

[Lenny Primak]

It's not only me that needs this. Many believe
that it's better to include tests into
the library being tested actually, makes
for better modularity and dependency tracking.
I am glad you understand now. Maybe my
hard work will pay off and i am not stuck
updating google test with a new patch
for every version with an exhaustive, time-consuming merge :)