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

2012-12-21 Thread 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


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

2011-12-19 Thread 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

2011-12-19 Thread 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

2011-12-19 Thread 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

2011-12-19 Thread 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

2011-12-19 Thread 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

2011-12-17 Thread 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

2011-12-17 Thread 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

2011-05-25 Thread 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?