[Bug libstdc++/48881] New: Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[Bug libstdc++/48881] New: Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[astrand at cendio dot se]

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

           Summary: Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll
                    produces broken binaries
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: astrand@cendio.se


We have been using GCC 4.4.3 with MinGW, producing binaries for Win32,
with good results. After upgrading to 4.5.2, libstdc++-6.dll and
libgcc_s_sjlj-1.dll have been added, but linking dynamically to these
does not work: All binaries crashes immediately at startup. Simply
deleting the DLL files from the build environment avoids the dynamic
link, and the binaries works. We are configuring gcc with:

./configure \
    --prefix=/usr --mandir=/usr/share/man \
    --target=i686-pc-mingw32 --disable-multilib \
    --with-sysroot=/usr/i686-pc-mingw32/sys-root \
    --disable-nls --disable-win32-registry \
    --without-included-gettext \
    --with-gnu-as --with-gnu-ld \
    --enable-sjlj-exceptions \
    --enable-version-specific-runtime-libs \
    --enable-threads=win32 --enable-languages=c,c++

[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dave.korn.cygwin at gmail
                   |                            |dot com, ktietz at gcc dot
                   |                            |gnu.org

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-25 09:51:37 UTC ---
Kai, Dave, can you have a look?

[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[ktietz at gcc dot gnu.org]

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

--- Comment #2 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-12-17 16:07:24 UTC ---
No idea.  I've tested this on my box (for 4.5.x and for 4.6.x) and don't get
this failure at all.  Shared version works as good as the static one.
So I assume that here something is broken with toolchain-build, or PATH
environment is setuped wrong.
Anyway I can't confirm this issue.  So I would suggest to close this issue as
WORKSFORME.

[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-12-17 16:33:06 UTC ---
Thanks. Let's do that.

[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[ossman at cendio dot se]

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

Pierre Ossman <ossman at cendio dot se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ossman at cendio dot se

--- Comment #4 from Pierre Ossman <ossman at cendio dot se> 2011-12-19 10:11:18 UTC ---
Well that was a bit rude. If this bug only appears under certain circumstances,
then shouldn't we try to find those circumstances rather than just saying that
if gcc works on your machine then that's good enough?

[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[ktietz at gcc dot gnu.org]

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

--- Comment #5 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-12-19 10:23:51 UTC ---
Well, I wouldn't say that this was rude.  The issue here is most likely, that
the runtime DLLs by gcc aren't in search-path when you are trying to execute
your built application.  But this isn't a subject of gcc itself.  I see that
you have this issue, but user-support questions on how to setup environment for
built applications, or what is necessary to provide along-side
built-application so that they run, is more something related to gcc's user ML,
or even better to ask directly for it on mingw.org's or mingw-w64's public
user-mailing lists.  On those later lists you can be sure that you will find a
solution for your issue.

[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[astrand at cendio dot se]

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

Peter Åstrand <astrand at cendio dot se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WORKSFORME                  |

--- Comment #6 from Peter Åstrand <astrand at cendio dot se> 2011-12-19 12:23:59 UTC ---
(In reply to comment #5)
> Well, I wouldn't say that this was rude.  The issue here is most likely, that
> the runtime DLLs by gcc aren't in search-path when you are trying to execute
> your built application. 

This is not how Windows works. If the DLLs aren't found, the application isn't
started at all. But in this case, the binaries do start, but immediately
crashes. Thus, this cannot be an installation problem. 

It's of course possible that our *build* of GCC is different in some way that
triggers this bug. But something is clearly wrong here, and as I mentioned in
the original report, 4.4.3 worked fine. We are working a Subversion based build
environment, and our build of 4.5.2 is therefore done in exactly the same way
as 4.4.3, which worked. We did however upgrade binutils from 2.20 to 2.21 in
the same step. We also migrated our thread fixes. I will attach both patches. 

Can you reproduce the problem if you are using the same settings as we?

[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[astrand at cendio dot se]

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

--- Comment #7 from Peter Åstrand <astrand at cendio dot se> 2011-12-19 12:24:44 UTC ---
Created attachment 26141
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26141
gcc-4.4.3-threads.patch

[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[astrand at cendio dot se]

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

--- Comment #8 from Peter Åstrand <astrand at cendio dot se> 2011-12-19 12:25:13 UTC ---
Created attachment 26142
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26142
gcc-4.5.2-threads.patch

[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries

[ktietz at gcc dot gnu.org]

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

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #9 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-12-21 16:26:11 UTC ---
Well, issue seems to be related to TLS-code of runtime you were using.
With more up-to-date runtime-version this is fixed for all mingw-flavors.
Additionally 4.5.x branch has reached already end of support, so I close this
as works-for-me