Hi,
Having different libgcc copies used from different parts of your program
may be a big problem or not, depending upon how it is used in your program.
Different libgccs do not share data, so C++ exceptions will not work
between different libgccs. Your C program may not care for exceptions but
dynamically allocated memory and other libgcc-stored data also can't be
passed around. This can lead to nasty random bugs, for instance with one
libgcc allocating memory and the other freeing it. If you are sure none of
this happening you can have different libgccs linked around, but why?
As Greg wrote, if you have more than single executable, the EXE and DLLs
should dynamically link libgcc and place all required DLLs in the same
directory the EXE is in. That's the first location Windows will look for
the DLLs, see
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
under "Standard Search Order for Desktop Applications".
Yaron
2015-04-02 1:16 GMT+03:00 Greg Jung <gvj...@gmail.com>:
> My 2c, which is not authoritative but perhaps can throw a few more
> topics into the mix.
> First remember this: there are compiler-specific versions of
> libstdc++, incompatible but nevertheless named the same, dependent
> upon the exception method deployed by the compiler.
> AFAIK the only way to force a user to find only the (shared lib)
> version of libstdc++ you designate is to include this where the .exe
> resides and to run the program from that directory (since you can't
> count on the path being set).
>
> If a program is linked with static libgcc, again AFAIK, libgcc is a
> dead end and doesn't need more support except what is commonly
> available, i.e. in windows/system32/... So a library built in the
> same manner
> will be using its own copies of libgcc routines and all of the names
> have been stripped, so there would be no clashes. If one of the libs
> used shared libgcc thats ok too, and libstd++ will use that instead of
> loading its own.
>
>
> On Tue, Mar 31, 2015 at 7:02 AM, Cosmin Apreutesei
> <cosmin.apreute...@gmail.com> wrote:
> > Hi,
> >
> > I'm looking for the best way to distribute binaries for a main exe and
> > several C and C++ plugins separately and I have a few questions about
> > linking libgcc and libstdc++.
> >
> > Currently, the main exe (a C program) is linked with static-libgcc.
> > Several C libraries that are loaded via LoadLibrary() are linked with
> > static-libgcc too.
> >
> > Is this setup supported? I.e. does libgcc have initialization or
> > shared globals that require it to be always linked dynamically or am I
> > ok to link it statically into multiple shared libraries like that?
> >
> > What happens if I also load a C++ library next? A C++ library will
> > pull in libstdc++ which will pull in a shared libgcc. Am I still on
> > solid ground here? Basically now I have libgcc statically linked into
> > the main exe _and_ dynamically linked from libstdc++.
> >
> > Good or no good?
> >
> > Thank you,
> > Cosmin.
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub
> for all
> > things parallel software development, from weekly thought leadership
> blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
