[Bug libstdc++/43877] container declaration disables standard output
--- Comment #5 from nico at josuttis dot de 2010-04-25 07:03 --- I gues with move.exe you mean my generated exe file. I have three versions here: cygcheck for the full buggy program (including vector declaration): --- 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 cygcheck for the working program (without vector declaration): -- D:\buecher\libbook2\book\code\cont\try\hello.exe P:\cygwin\bin\cygstdc++-6.dll P:\cygwin\bin\cyggcc_s-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 cygcheck for a working program with g++4.4.3(with vector declaration): -- 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 Hmm, looks probably not correct that the cygwin libs are used: P:\cygwin\bin\cygstdc++-6.dll P:\cygwin\bin\cyggcc_s-1.dll which would mean that options such as --prefix=/cygdrive/p/gcc4 --program-suffix=4 --with-gxx-include-dir=/cygdrive/p/gcc4-include would not work properly or be enough. Attached you also get the exe file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug libstdc++/43877] container declaration disables standard output
--- Comment #6 from nico at josuttis dot de 2010-04-25 07:06 --- Created an attachment (id=20480) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20480action=view) hello.exe for the buggy 4.5.0 version (with declared vector) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug libstdc++/43877] container declaration disables standard output
--- Comment #7 from nico at josuttis dot de 2010-04-25 07:25 --- compiling with -static also fixes the problem, which also supports the theory of using wrong DLL's. The only question is, why are the wrong libs used without -static. Any idea? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug libstdc++/43877] container declaration disables standard output
--- 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.) -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug libstdc++/43877] container declaration disables standard output
--- 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 +49 (0)700 / JOSUTTIS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug libstdc++/43877] container declaration disables standard output
--- Comment #1 from nico at josuttis dot de 2010-04-24 10:16 --- compiler built with: ../src/gcc-4*/configure --prefix=/cygdrive/p/gcc4 --program-suffix=4 --with-gxx-include-dir=/cygdrive/p/gcc4-include example compiled with: g++4 -std=c++0x move.cpp -o move -- nico at josuttis dot de changed: What|Removed |Added Summary|container declaration |container declaration |disables standard outoput |disables standard output http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug libstdc++/43877] container declaration disables standard output
--- Comment #2 from paolo dot carlini at oracle dot com 2010-04-24 23:28 --- Totally crazy. Dave can you reproduce this? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug libstdc++/43877] container declaration disables standard output
--- Comment #3 from davek at gcc dot gnu dot org 2010-04-24 23:33 --- (In reply to comment #2) Totally crazy. Dave can you reproduce this? I have a theory. Will report back in ten minutes or so... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
[Bug libstdc++/43877] container declaration disables standard output
--- Comment #4 from davek at gcc dot gnu dot org 2010-04-24 23:44 --- (In reply to comment #3) (In reply to comment #2) Totally crazy. Dave can you reproduce this? I have a theory. Will report back in ten minutes or so... Uh, well, nope, that didn't work. I was wondering if the code might have been using some new export from the DLL that didn't exist back in 4.3.4 days, and that would cause problems if the distro's dll was in $PATH ahead of the newly built one, but then I tried it and it worked fine. However, this problem is symptomatic of a missing DLL, or a DLL which doesn't have an expected export. Nicolai, please run cygcheck ./move.exe and paste the results into the PR, and please zip up and attach the generated exe file and I'll try and figure out what went wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
