Re: [lmi] shared libstdc++ for mingw32

[Greg Chicares]

On 2005-8-5 16:41 UTC, Vadim Zeitlin wrote:
> 
>  I've decided to switch this discussion here so that we could reference it
> in the archives later.

Good idea, thanks. What we had been discussing off the list is related
to 'ChangeLog' entries dated 20050804T0220Z and20050805T1702Z. The
specific problem was:

| We have one exe with three dlls (aside from the msw system dlls):
|   lmi_wx_shared.exe
|     liblmi.dll
|     wx_new.dll
|     /usr/local/bin/wxmsw254d_gcc_custom.dll
| In this test case, an exception is thrown from 'lmi_wx_shared.exe'
| and caught in the monolithic wx dll by a handler that calls the
| overridden wxApp::OnExceptionInMainLoop(); thus, the monolithic
| dll calls back virtually into the main application, and then...
|
| (1) if the main application rethrows the exception itself, it
  [calls std::terminate()]
|
| (2) if the main application calls back into the monolithic wx dll,
| invoking a function that executes 'throw;' in that dll--the exact
| same dll that first threw the exception--then everything works.
|
| (3) if the main application calls back into a different wx dll
| (the non-monolithic case), then it
  [calls std::terminate()]

So cvs as of this instant works with msw only if wx is built
monolithically--a somewhat bizarre restriction that you're
trying to work around by building a shared libstdc++ .

>  First the good news: I did manage to make my sample to work by creating a
> shared libstdc++.dll using the commands
> 
>       dlltool --export-all --output-exp a.exp --dllname libstdc++.dll \
>               --output-lib libstdc++.dll.a /mingw/lib/libstdc++.a
>       gcc -shared a.exp /mingw/lib/libstdc++.a -o libstdc++.dll
> 
> If I move this libstdc++.dll to /mingw/lib and remove the original
> libstdc++.a, then the sample builds with a single linker message (it's not
> even a warning):
> 
> Info: resolving typeinfo for intby linking to __imp___ZTIi (auto-import)
> 
> and works correctly. As a nice side effect, it's also signficantly smaller,
> of course.
> 
> 
>  Second the bad news: the libstdc++.dll I "built" using the above commands
> seems to be not 100% working. First of all, the dll.a file produced doesn't
> work at all: if I copy it to /mingw/lib (so that it is used instead of
> directly taking the symbols from DLL [nice, I didn't know mingw could do
> this]), I get errors:
> 
> fu000001.o(.idata$3+0xc): undefined reference to `libstdc___dll_a_iname'
> fu000002.o(.idata$3+0xc): undefined reference to `libstdc___dll_a_iname'
> nmth000000.o(.idata$4+0x0): undefined reference to `_nm___ZTIi'
> collect2: ld returned 1 exit status
> 
> And if I don't use it but use just the libstd++.dll, the wx DLLs can't be
> built as I get tons of errors like this:
> 
> variable 'vtable for __cxxabiv1::__vmi_class_type_info' can't be
> auto-imported. Please read the documentation for ld's --enable-auto-import
> for details.
> 
>  Conclusion: it seems clear that using shared libstdc++.dll does solve the
> problem. It's also clear that the dlltool hack I used to create it from
> static lib doesn't quite work. If you agree with using the dll, then
> someone should look into building it correctly. Using the DLL has
> obvious advantages: exceptions work, total size is smaller and linking
> faster but also a disadvantage: it is not standard and so is another setup
> step. I do believe it's worth it though. BTW, the reason libstdc++.dll is
> not included in mingw32 is because some people think that using it would
> force any applications compiled with g++ to fall under GPL. I don't see how
> can anyone seriously believe this but in any case this is not a problem for
> lmi, of course.

It's enough if the mingw developers believe that. [But see below.]

I think FSF might believe it, too, and they own this server; but
the right place to discuss that is news:gnu.misc.discuss of course.

However, that makes no difference to the lmi project, which is GPL
by choice, and must conform to GPL anyway because it uses other
GPL code.

>  Please let me know if I should continue with trying to build a working
> libstdc++.dll. If the answer is yes, I'd prefer to do it now rather than
> return to it later and lose time in "context switches".

I'd conclude that it's not a good use of your time because I think the
following snippets from mailing-list messages posted by three of the
MinGW developers suggest that
 - they may not see GPL as being the issue, and, more conclusively,
 - they want to make libstdc++ a dll in the long term
If Danny in particular wants to do this, but hasn't yet, then I would
guess that it's rather difficult. And we can live with the requirement
to build wx monolithically.

Danny Smith, 17 Jul 2005 09:34:35 +1200
| I prefer the long-term solution of  gettiung libgcc and libstdc++ shared
| library support working.

Earnie Boyd, 17 Sep 2003 14:15:44 -0400
| > How  can  I have a "libstdc++.dll" (or something like that)
| > which I can distribute with my application?
|
| Yes it is possible.  You would need to grab the source from MinGW and
| --enable-shared when configuring.  I do not know the level of effort
| you'll need beyond that.

Luke Dunstan, 16 Apr 2003 10:53:28 +0800
| If it is really important to you then you might try building libstdc++
| as a DLL but I don't know how difficult it would be. I seem to remember
| that many people didn't want this to become the default for MinGW because
| it would cause too many problems with using the wrong version of the DLL
| at runtime, but that might be out of date.