[Bug libstdc++/43877] New: container declaration disables standard outoput

[Bug libstdc++/43877] New: container declaration disables standard outoput

[nico at josuttis dot de]

With g++ 4.5.0 built on cygwin pc (x86, 32bit) the following
program has no output. Without the declaration of the vector
anything works fine as expected.
Does anybody know what could cause this strange behavior?

#include <iostream>
#include <vector>

int main()
{
    std::cout << "hello" << std::endl;
    std::vector<int> v;
}


-- 
           Summary: container declaration disables standard outoput
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: nico at josuttis dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877

[Bug libstdc++/43877] container declaration disables standard output

[nico at josuttis dot de]

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

[paolo dot carlini at oracle dot com]

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

[davek at gcc dot gnu dot org]

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

[davek at gcc dot gnu dot org]

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

[Bug libstdc++/43877] container declaration disables standard output

[nico at josuttis dot de]

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

[nico at josuttis dot de]

------- 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=20480&action=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

[nico at josuttis dot de]

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

[davek at gcc dot gnu dot org]

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

[nico at josuttis dot de]

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