This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Yaakov (Cygwin/X) wrote:
> Dave Korn wrote:
>> Plain C applications will, by default, be linked statically against libgcc as
>> previously. To link against the shared libgcc DLL, '-shared-libgcc' must be
>> manually specified on the command-line.
> 1) What exactly are the pros and cons of this? IOW, why should we *not*
> want to use shared libgcc?
No reason that I can think of in general. The only case would be when you
really need to override intra-libstdc++ calls to operators new and delete, in
which case you need to link the whole thing statically.
Also, some 3PPs will get warm fuzzies from having one less DLL to
distribute, though it hardly makes the resulting executables any more
> 2) How can -shared-libgcc (or -static-libgcc, for that matter) be passed
> when building with libtool so that it actually gets passed on to gcc?
Errr, dunno. It's a standard GCC command-line option, libtool ought to be
taught to understand it - surprised it doesn't already.
>> The to-do list for the first fully stable release currently stands at:
>> - Implement improved weak symbol handling in Win32 PE binutils, to resolve C++
>> operator new/delete interposition problem with shared libstdc++.
>> - Add support scripts for default compiler switching.
> std::wstring for cygwin-1.7? Please??
Oh, sorry! Forgot. Adding it to the list now give us:
The to-do list for the first fully stable release currently stands at:
- Implement improved weak symbol handling in Win32 PE binutils, to resolve C++
operator new/delete interposition problem with shared libstdc++.
- Add support scripts for default compiler switching.
- std::wstring for cygwin-1.7!
- investigate fortran testsuite problems.
- investigate java testsuite run test failures.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html