------- 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
