------- Comment #9 from nico at josuttis dot de 2010-04-25 14:15 ------- Subject: Re: container declaration disables standard output
Thanks a lot, Paolo and Dave. The explanation makes total sense to me and putting gcc 4.5.0 in front of the path fixes the problem. I would have searched very long (especially as I didn't know cygcheck and the history of exception handling models). Best regards Nico davek at gcc dot gnu dot org schrieb/wrote: > ------- Comment #8 from davek at gcc dot gnu dot org 2010-04-25 12:14 ------- >> P:\gcc4\bin\cyggcc_s-sjlj-1.dll > > This is the source of all your problems. Sorry, I should have been able to > work this out just from seeing your configure line earlier. > > The SJLJ and DW2 EH models are incompatible. This is a copy of the shared > libgcc dll built using sjlj exceptions, and it won't be compatible with any of > the other DLLs in your system. In particular: > > D:\buecher\libbook2\book\code\cont\try\hello.exe > P:\gcc4\bin\cyggcc_s-sjlj-1.dll > P:\cygwin\bin\cygwin1.dll > C:\WINDOWS\system32\ADVAPI32.DLL > C:\WINDOWS\system32\KERNEL32.dll > C:\WINDOWS\system32\ntdll.dll > C:\WINDOWS\system32\RPCRT4.dll > C:\WINDOWS\system32\Secur32.dll > P:\cygwin\bin\cygstdc++-6.dll > P:\cygwin\bin\cyggcc_s-1.dll > > ... note how you have *two* different kinds of incompatible libgcc_s DLL > loaded > into the same application, one directly from the app, one that libstdc++ > itself > is using. They're not going to get along well! > > In order to build GCC so that the newly-generated DLLs (and hence the exes > that > link to them) are compatible with the DLLs in the Cygwin distro, it's always > necessary to configure with --disable-sjlj-exceptions. (Yes, this should > become the default now that 1.7 is out.) > > It's also probably the case that your app would work if you got rid of the > standard distro versions of the libstdc++ and libgcc_s DLLs and made sure your > executable consistently used the newly-built ones; part of the problem is > caused becuase on windows we can't embed full paths to libraries in an > application when linking, meaning that we can't build the exes so that they > know which of your two libstdc++ DLLs they actually want to link to. So your > app, which was built by a gcc that "knows" it wants to use SJLJ EH, links > against libgcc_s-sjlj; but because this naming scheme isn't (yet) extended to > the other language runtimes, it links against > any-old-libstdc-that-comes-first-in-the-path. In general, if you're building > and using a custom GCC in a different --prefix setting, make sure to put that > $prefix/bin first in your path at all times, so that your applications always > load the freshly-built versions of the DLLs when they run. I'm guessing > you've > got it somewhere late in your path, so that when you launch your app the > windows OS loader finds the standard libstdc++ DLL first. > > This should hopefully also make it clear why you don't see any problems with > -static; your code gets linked by gcc against the static libraries that came > with that particular gcc; it's only when using DLLs, where the windows OS > loader doesn't know anything about which DLL to use so it chooses the first in > the path, that this kind of mixup can happen. > > (As general advice, when you're building GCC on any system, always run "gcc > -v" > on the existing system compiler and take a look at how it was configured; try > and follow the existing options whenever they relate to important > code-generation stuff like exception handling methods.) > > -- Nicolai M. Josuttis SOA in Practice http://soa-in-practice.com IT communication http://it-communication.com Solutions in Time http://www.josuttis.de +49 (0)531 / 129 88 86 +49 (0)700 / 5678 8888 +49 (0)700 / JOSUTTIS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
