Google Test does not support compiling into Windows DLL - I have a patch

[Lenny Primak]

Hi Google test users:
Does anyone have any experience with working with google test
under windows DLL environment?

This is from Issue 214:

Some 3rd party libraries come only in DLL form. If another library
(the
one I am developing) uses the 3rd party DLL, and uses google test in
any way,
it either has to be DLL (thus google test has to be DLL) or
you get link errors when linking the executable, due to multiply-
defined
symbols that are being brought in by static google-test library.

What version of the product are you using? On what operating system?
Windows XP, Visual Studio 9 (2008).

I have a patch for google test 1.3.0
that introduces DLL_EXPORT_XXX macros in most include files
to be able to generate working DLL on windows.
It is attached

[Prashant]

great! I had similar issue where my third party library comes in dll
format.
Just one question, does this patch applies to google test 1.4.0?

Thanks,
Prashant

On Nov 3, 1:11 pm, Lenny Primak <lennypri...@gmail.com> wrote:
> Hi Google test users:
> Does anyone have any experience with working with google test
> under windowsDLLenvironment?
>
> This is from Issue 214:
>

> Some 3rd party libraries come only inDLLform.  If another library
> (the
> one I am developing) uses the 3rd partyDLL, and uses google test in
> any way,
> it either has to beDLL(thus google test has to beDLL) or

[Vlad Losev]

Hi Lenny,

Sorry for a tardy response and thanks for the suggestion.

Some people link Google Test as a DLL, and we understand their need. Most people, however, link it as a static library to their main program where they define their tests. This works even if the code they test lives in a separate DLL. We chose to concentrate on those people. Adding the export macros has been discussed in this thread on our mailing list.

By the way, a linker definition file listing exports of Google Test can also solve your problem. And we will welcome a contribution of such a file. :-)

Regards,
Vlad

[Lenny Primak]

Sorry, this is 1.3.0 patch only.
You can try it on 1.4.0 and fix the errors as they come up.
Maybe contribute the patch for 1.4.0 too?

[Zhanyong Wan (λx.x x)]

On Fri, Nov 13, 2009 at 10:40 AM, Lenny Primak <lenny...@gmail.com> wrote:
> Sorry, this is 1.3.0 patch only.
> You can try it on 1.4.0 and fix the errors as they come up.
> Maybe contribute the patch for 1.4.0 too?

If someone is working on this and want the patch to be accepted (and
thus become part of future gtest releases), it helps a lot to write
the patch against the SVN trunk head instead of an already-released
version. Thanks!

--
Zhanyong

[Lenny Primak]

Im willing to do this if you guys are willing to accept my patch.
I signed all the committer documents.
Right now the issue says 'WontFix'

On Nov 13, 2:32 pm, Zhanyong Wan (λx.x x) <w...@google.com> wrote:

[Vlad Losev]

Hi Lenny,

On Fri, Nov 13, 2009 at 11:41 AM, Lenny Primak <lenny...@gmail.com> wrote:

Im willing to do this if you guys are willing to accept my patch.
I signed all the committer documents.
Right now the issue says 'WontFix'

Thanks for offering the patch. We recognize that people use gtest in many different configurations, and strive for it to be a useful tool for all of them. We now have multiple inquiries to make gtest work as a DLL, and that notches its priority up. However, sticking those export macros into the source code makes it harder to work with. As a guy who works with that code a lot I would like to avoid it, if there is an alternative way of exporting those classes and functions. A couple of weeks from now I will have time to write a linker definition file, which is another way of exporting symbols from a dll. It is generally labor-intensive but I'll see if I can script creation of such file.

I'll mark the issue as 'accepted' meanwhile.

Regards,
Vlad

[Lenny Primak]

Thanks, Vlad.
Unfortunately, I have been up that (scripting .def files) road myself.
In fact, that's the first thing I tried to do when tried to port s/w
to MS platform.
I am with you in the opinion that it would be much better to use
a .def file
instead of these bloody macros, the reality of current state of
Microsoft tools,
it is technically infeasible right now.

On Nov 17, 1:59 pm, Vlad Losev <vl...@google.com> wrote:
> Hi Lenny,
>

[Vlad Losev]

Hi Lenny,

On Mon, Nov 23, 2009 at 10:13 PM, Lenny Primak <lenny...@gmail.com> wrote:

Thanks, Vlad.
Unfortunately, I have been up that (scripting .def files) road myself.
In fact, that's the first thing I tried to do when tried to port s/w
to MS platform.
I am with you in the opinion that it would be much better to use
a .def file
instead of these bloody macros, the reality of current state of
Microsoft tools,
it is technically infeasible right now.

If MS doesn't provide good tools, one can write his own. :-)

In all seriousness, for those of us who are not using IDEs and often use grep to find things in the source code, those macros may be a not just aesthetic annoyance but a practical problem. I am going to take a shot at writing the .def file first. I understand this is not a trivial task, an there are caveats. It may not work out, and in that case your patch goes in. I will let you know how it goes.

Regards,
Vlad

[Lenny Primak]

Have fun. Really hope it works for you better than it worked for me.
If I remember correctly, I actually got close by using dlltool from
cygwin
on the generated object files. Unfortunately, it wasn't close enough
and i was still getting undefined symbols.

On Nov 24, 5:17 pm, Vlad Losev <vl...@google.com> wrote:
> Hi Lenny,
>

[Vlad Losev]

Hi Lenny,

I have some preliminary results. Can you please see if this .def file works for you? You may have to adjust the library name in the LIBRARY section to match the library file name (sans .dll) or your program may fail to run. This set of exports is based on the actual documented functionality. But it may be incomplete and it isn't supporting any undocumented use of gtest.

Let me know if this works for you and I will set this file and the supporting code on its way to the source code repository.

Thanks,
Vlad

[Lenny Primak]

Vlad, I am on vacation til Tuesday.
I will probably get to this on Wed the earliest.
Will tell you the results as soon as I can.

On Dec 10, 5:27 pm, Vlad Losev <vladlo...@gmail.com> wrote:
> Hi Lenny,
>
> I have some preliminary results. Can you please see if this .def file works
> for you? You may have to adjust the library name in the LIBRARY section to
> match the library file name (sans .dll) or your program may fail to run.
> This set of exports is based on the actual documented functionality. But it
> may be incomplete and it isn't supporting any undocumented use of gtest.
>
> Let me know if this works for you and I will set this file and the
> supporting code on its way to the source code repository.
>
> Thanks,
> Vlad
>

>  gtest.def
> 7KViewDownload

[Zhanyong Wan (λx.x x)]

Thanks for working on this, Vlad!

I took a look at the file. Wow, it's quite a feat. Did you do it by
hand? I hope you have some tool to somewhat automate the generation
of the .def file. Can't imagine how we can maintain and review it
manually. :-(

--
Zhanyong

[Vlad Losev]

Hi Zhanyong,

2009/12/11 Zhanyong Wan (λx.x x) <w...@google.com>

Thanks for working on this, Vlad!

I took a look at the file.  Wow, it's quite a feat.  Did you do it by
hand?  I hope you have some tool to somewhat automate the generation
of the .def file.  Can't imagine how we can maintain and review it
manually. :-(

It did involve quite a bit of manual coding. But I can assure you, the review and maintenance are going to be a lot easier than writing it. :-)

- Vlad

[Lenny Primak]

Well, Vlad, you are glutton for punishment :)
I suppose if it works and is maintained that's good enough for me.

BTW, Zhanyong, Gene Volovich says hi.
He moved back to Connecticut.

On Dec 11, 3:11 pm, Vlad Losev <vladlo...@gmail.com> wrote:
> Hi Zhanyong,
>
> 2009/12/11 Zhanyong Wan (λx.x x) <w...@google.com>
>
> > Thanks for working on this, Vlad!
>
> > I took a look at the file.  Wow, it's quite a feat.  Did you do it by
> > hand?  I hope you have some tool to somewhat automate the generation
> > of the .def file.  Can't imagine how we can maintain and review it
> > manually. :-(
>
> > It did involve quite a bit of manual coding. But I can assure you, the
>
> review and maintenance are going to be a lot easier than writing it. :-)
>
>
>
> > On Thu, Dec 10, 2009 at 2:27 PM, Vlad Losev <vladlo...@gmail.com> wrote:
> > > Hi Lenny,
> > > I have some preliminary results. Can you please see if this .def file
> > works
> > > for you? You may have to adjust the library name in the LIBRARY section
> > to
> > > match the library file name (sans .dll) or your program may fail to run.
> > > This set of exports is based on the actual documented functionality. But
> > it
> > > may be incomplete and it isn't supporting any undocumented use of gtest.
> > > Let me know if this works for you and I will set this file and the
> > > supporting code on its way to the source code repository.
> > > Thanks,
> > > Vlad
>

> > > On Wed, Nov 25, 2009 at 12:15 AM, Lenny Primak <lennypri...@gmail.com>

[Lenny Primak]

For the most part, it works, but few are missing.
This, is by no means a comprehensive list
because we are not using a lot of features of gtest.

The other thing is a big PITA that I have
to create/tweak the solution files to
generate the DLL.
Also, for the debug/release output formats,
the files have to be different due to the
different name of the DLL.

Perhaps this could also be remedied?

Overall, good job, even though I still think
macros would be easier going forward.


Error 1 error LNK2019: unresolved external symbol
"class testing::internal::String __cdecl
testing::internal::FormatForFailureMessage(char)" (?
FormatForFailureMessage@internal@testing@@YA?AVString@12@D@Z)
referenced in function "class testing::internal::String __cdecl
testing::internal::FormatForComparisonFailureMessage<char,char>(char
const &,char const &)" (??
$FormatForComparisonFailureMessage@DD@internal@testing@@YA?
AVString@01@ABD0@Z) DbTest.obj test

Error 1 error LNK2019: unresolved external symbol
"public: static class testing::internal::String __cdecl
testing::internal::String::ShowCStringQuoted(char const *)" (?
ShowCStringQuoted@String@internal@testing@@SA?AV123@PBD@Z) referenced
in function "class testing::internal::String __cdecl
testing::internal::FormatForComparisonFailureMessage(char const
*,class std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > const &)" (?
FormatForComparisonFailureMessage@internal@testing@@YA?
AVString@12@PBDABV?$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@@Z) DbTest.obj test

Error 2 error LNK2001: unresolved external symbol
"public: static class testing::internal::String __cdecl
testing::internal::String::ShowCStringQuoted(char const *)" (?
ShowCStringQuoted@String@internal@testing@@SA?
AV123@PBD@Z) UtilityTest.obj test

On Dec 10, 5:27 pm, Vlad Losev <vladlo...@gmail.com> wrote:
> Hi Lenny,
>
> I have some preliminary results. Can you please see if this .def file works
> for you? You may have to adjust the library name in the LIBRARY section to
> match the library file name (sans .dll) or your program may fail to run.
> This set of exports is based on the actual documented functionality. But it
> may be incomplete and it isn't supporting any undocumented use of gtest.
>
> Let me know if this works for you and I will set this file and the
> supporting code on its way to the source code repository.
>
> Thanks,
> Vlad
>

>  gtest.def
> 7KViewDownload

[Vlad Losev]

Hi Lenny,

Thanks for the feedback! Please see if the updated file works for you. 

On Tue, Dec 15, 2009 at 3:39 AM, Lenny Primak <lenny...@gmail.com> wrote:

For the most part, it works, but few are missing.
This, is by no means a comprehensive list
because we are not using a lot of features of gtest.

My goal is to have a .def file that covers all documented gtest API, so as you should be covered as you start using more features in gtest. 

 

The other thing is a big PITA that I have
to create/tweak the solution files to
generate the DLL.

One way to deal with that is to create a patch over the difference between static/shared library project and then automatically apply that patch after unpacking a new gtest distribution or grabbing a version from svn.

 

Also, for the debug/release output formats,
the files have to be different due to the
different name of the DLL.

Perhaps this could also be remedied?

The updated .def file does away with the library name in the LIBRARY section. That should take care of this problem.

 

Overall, good job, even though I still think
macros would be easier going forward.

I am building a semi-automated way to update the .def file. Using macros will require manual updates of the source code, so I am not sure they will be easier to maintain.

Thanks for the diagnostics. Missed those in my initial test case. :-(

Regards,

Vlad

[Lenny Primak]

Vlad,
The new .def file works for us now.

However, the .def file isn't the only thing I had to do
to make this work.
Can I please ask you that the DLL support will be 'official'
here? I am sure I am not the only one who's asking.
To make the support official, I request that you
add a solution/project for the DLL builds.
Ultimately, the DLL build should be the default build of google
test on windows. Also, maybe the scons build should
be updated to build the DLL as well (i don't use it but still a good
idea)
If the DLL support comprises the .def file only, it will
be forgotten as a disconnected appendage and will eventually
stop being supported.

Thanks for all the work and I look forward to using
future versions of google test with minimum fuss as a DLL 'as is'
without further patching/mucking :)

On Dec 15, 6:03 am, Vlad Losev <vladlo...@gmail.com> wrote:
> Hi Lenny,
>

> Thanks for the feedback! Please see if the updated file works for you.
>

>  gtest.def
> 8KViewDownload

[Vlad Losev]

Hi Lenny -

gtest in the DLL configuration is not used inside Google, so it will not be officially supported in a sense that we will not be actively testing it and making sure it remains working and covers all the new features in the library.

We will add a test to validate the configuration to our CI build to have a reasonable confidence in it. But that test may not have the complete coverage. It will ultimately fall on our users to spot and report issues with the configuration.

Having sai that, it is not problem to add a project for the DLL configuration (and probably a test) to gtest.sln. 

- Vlad

[Lenny Primak]

So I understand correctly that you will add a DLL
configuration into the source control and I don't have
to do eat with each new release. Thanks if that is the case.
I appreciate the effort.
And, since GTest is an open source project, users/contributors
should be considered in what's 'supported' or not :)
Anyway, have a great evening.

On Dec 15, 11:07 pm, Vlad Losev <vladlo...@gmail.com> wrote:
> Hi Lenny -
>
> gtest in the DLL configuration is not used inside Google, so it will not be
> officially supported in a sense that we will not be actively testing it and
> making sure it remains working and covers all the new features in the
> library.
>
> We will add a test to validate the configuration to our CI build to have a
> reasonable confidence in it. But that test may not have the complete
> coverage. It will ultimately fall on our users to spot and report issues
> with the configuration.
>
> Having sai that, it is not problem to add a project for the DLL
> configuration (and probably a test) to gtest.sln.
>

> ...
>
> read more »

[Zhanyong Wan (λx.x x)]

Vlad's DLL-support patch is in r354 of the trunk. The final details
may change when the next version of gtest is released, but you can at
least experiment with it now.

--
Zhanyong

[Zhanyong Wan (λx.x x)]

We moved gtest.def to a new location (msvc/) in r355. Thanks,

2009/12/17 Zhanyong Wan (λx.x x) <w...@google.com>:

--
Zhanyong