Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: Update mingw32-runtime to 3.18
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Summary: Update mingw32-runtime to 3.18 Product: Fedora Version: 14 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-runtime AssignedTo: rjones@redhat.com ReportedBy: atkac@redhat.com QAContact: extras-qa@fedoraproject.org CC: rjones@redhat.com, kalev@smartlink.ee, fedora-mingw@lists.fedoraproject.org Classification: Fedora Target Release: ---
Description of problem: When I compile TigerVNC vncviewer for Windows on Fedora 14/rawhide, output vncviewer.exe binary is broken:
... Backtrace: =>0 0x00485e4f in vncviewer (+0x85e4f) (0x00a0fe30) 1 0x0040108d __mingw_CRTStartup+0x6c() [/builddir/build/BUILD/mingwrt-3.15.2-mingw32/crt1.c:217] in vncviewer (0x00a0fe70) 2 0x0040108d __mingw_CRTStartup+0x6c() [/builddir/build/BUILD/mingwrt-3.15.2-mingw32/crt1.c:217] in vncviewer (0x00a0fe90) 3 0x00401128 WinMainCRTStartup+0x17() [/builddir/build/BUILD/mingwrt-3.15.2-mingw32/crt1.c:271] in vncviewer (0x00a0fea8) 4 0x7ede70bc call_process_entry+0xb() in kernel32 (0x00a0fee8) 5 0x7efab570 call_thread_func+0xb() in ntdll (0x00a0fef8) 6 0x7efae1f1 call_thread_entry_point+0x70() in ntdll (0x00a0ffc8) 7 0x7ef83feb call_dll_entry_point+0x65a() in ntdll (0x00a0ffe8) ...
When I updated to the latest mingw runtime from upstream (mingwrt-3.18-mingw32-src) everything works fine.
Version-Release number of selected component (if applicable): mingw32-runtime-3.15.2-5.fc13
How reproducible: always
Steps to Reproduce: 1. compile program for Windows via MinGW build chain 2. run it
Actual results: crash
Expected results: working binary
Additional info: It seems current mingw runtime is not compatible with gcc 4.5. As I wrote above when I update to 3.18 version, problem disappears.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #1 from Richard W.M. Jones rjones@redhat.com 2010-09-03 03:29:31 EDT --- Adam, request co-maint on this package and then you will be able to check in the update yourself.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Adam Tkac atkac@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|rjones@redhat.com |atkac@redhat.com
--- Comment #2 from Adam Tkac atkac@redhat.com 2010-09-06 03:48:30 EDT --- (In reply to comment #1)
Adam, request co-maint on this package and then you will be able to check in the update yourself.
Done, I will handle this issue.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #3 from Fedora Update System updates@fedoraproject.org 2010-09-06 03:57:16 EDT --- mingw32-runtime-3.18-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/mingw32-runtime-3.18-1.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #4 from Kalev Lember kalev@smartlink.ee 2010-09-06 06:59:15 EDT --- mingw32-gcc doesn't appear to build against mingw32-runtime-3.18, see http://koji.fedoraproject.org/koji/getfile?taskID=2449090&name=build.log
Creating library file: .libs/libgfortran.dll.a/builddir/build/BUILD/gcc-4.5.1/build/./gcc/libgcc_eh.a(unwind-sjlj.o): In function `__gthread_key_create': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:582: undefined reference to `_TlsAlloc@0' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:589: undefined reference to `___mingwthr_key_dtor' /builddir/build/BUILD/gcc-4.5.1/build/./gcc/libgcc_eh.a(unwind-sjlj.o): In function `__gthread_setspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `_TlsSetValue@8' /builddir/build/ BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `_TlsSetValue@8' /builddir/build/BUILD/gcc-4.5.1/build/./gcc/libgcc_eh.a(unwind-sjlj.o): In function `__gthread_getspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `_SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/./gcc/libgcc_eh.a(unwind-sjlj.o): In function `__gthread_setspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `_TlsSetValue@8' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `_TlsSetValue@8' /builddir/build/BUILD/gcc-4.5.1/build/./gcc/libgcc_eh.a(unwind-sjlj.o): In function `__gthread_getspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `_SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `_SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `_SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `_SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `_SetLastError@4' collect2: ld returned 1 exit status
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #5 from Richard W.M. Jones rjones@redhat.com 2010-09-06 08:51:06 EDT --- Also this broke another build: http://koji.fedoraproject.org/koji/getfile?taskID=2449333&name=build.log
libtool: link: i686-pc-mingw32-gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -o .libs/portable-rpcgen.exe portable_rpcgen-rpcgen_parse.o portable_rpcgen-rpcgen_scan.o portable_rpcgen-rpcgen_main.o portable_rpcgen-rpcgen_ast.o portable_rpcgen-rpcgen_codegen.o /usr/lib64/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_key_create': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:582: undefined reference to `TlsAlloc@0' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:589: undefined reference to `__mingwthr_key_dtor' /usr/lib64/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_once': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:554: undefined reference to `InterlockedIncrement@4' /usr/lib64/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_setspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `TlsSetValue@8' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `TlsSetValue@8' /usr/lib64/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_getspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' /usr/lib64/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_setspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `TlsSetValue@8' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `TlsSetValue@8' /usr/lib64/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_getspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' make[1]: Leaving directory `/builddir/build/BUILD/portablexdr-4.9.1' make[1]: *** [portable-rpcgen.exe] Error 1
It seems like this mingw32-runtime package is broken, or we're Doing It Wrong somehow.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Daniel Berrange berrange@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berrange@redhat.com
--- Comment #6 from Daniel Berrange berrange@redhat.com 2010-09-06 14:29:25 EDT --- The 3.18 release changelog has this ominous, but rather uninformative, note:
2010-01-25 Kai Tietz kai.tietz@onevision.com
Implement TLS Callback.
* tlsmcrt.c: New file. * tlsmthread.c: Ditto. * tlssup.c: Ditto. * tlsthrd.c: Ditto. * Makefile.in: Include new files. * crt1.c: Implement TLS Callback. * dllcrt1.c: Ditto. * mthr_stub.c: Remove.
It appears to have impacted Boost too
https://groups.google.com/group/boost-list/browse_thread/thread/1146284e83aa...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA
--- Comment #7 from Fedora Update System updates@fedoraproject.org 2010-09-07 02:46:37 EDT --- mingw32-runtime-3.18-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update mingw32-runtime'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/mingw32-runtime-3.18-1.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #8 from Richard W.M. Jones rjones@redhat.com 2010-09-07 07:12:31 EDT --- Basically after a long discussion with Kai Tietz, we came to the conclusion that mingw32-runtime 3.18 TLS support is just fundamentally broken. I think we should immediately revert this package back to 3.17.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #9 from Richard W.M. Jones rjones@redhat.com 2010-09-07 07:13:17 EDT --- .. and switch to mingw-w64 as soon as we can.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #10 from Daniel Berrange berrange@redhat.com 2010-09-07 07:20:39 EDT --- I'm wondering if the problem is due to Fedora using SJLJ exception handling ? The official MinGW gcc 4.5.x builds are all done using DWARF2 exceptions, so I wouldn't be surprised if they didn't test the TLS+SJLJ combination.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #11 from Adam Tkac atkac@redhat.com 2010-09-07 08:07:28 EDT --- (In reply to comment #8)
Basically after a long discussion with Kai Tietz, we came to the conclusion that mingw32-runtime 3.18 TLS support is just fundamentally broken. I think we should immediately revert this package back to 3.17.
I've just tested 3.17 and there are same issues as written in the comment #5. It seems this issue is not related to the TLS implementation.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #12 from Adam Tkac atkac@redhat.com 2010-09-07 08:16:43 EDT --- Another interesting information is that mingw32-runtime-3.15.2-5 rebuilt with the latest mingw32-gcc-4.5.1-1.fc15 is broken as well.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #13 from Richard W.M. Jones rjones@redhat.com 2010-09-07 08:51:36 EDT --- (In reply to comment #12)
Another interesting information is that mingw32-runtime-3.15.2-5 rebuilt with the latest mingw32-gcc-4.5.1-1.fc15 is broken as well.
I've tried all sorts of combinations, even removing every mingw32 package and going back to the ones from May to build a reverted 1:mingw32-runtime-3.15.2-5, with no luck so far at all.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #14 from Daniel Berrange berrange@redhat.com 2010-09-07 09:03:12 EDT --- In my tests any mingw-runtime version built against gcc 4.5.x is fubar. I've only been able to get good builds using gcc 4.4.x from F13 mingw era
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #15 from Adam Tkac atkac@redhat.com 2010-09-07 09:17:44 EDT --- (In reply to comment #14)
In my tests any mingw-runtime version built against gcc 4.5.x is fubar. I've only been able to get good builds using gcc 4.4.x from F13 mingw era
Same here, it seems gcc 4.5 is broken.
I dug more about missing symbols and it seems all symbols are defined in /usr/i686-pc-mingw32/sys-root/mingw/bin/mingwm10.dll and /usr/i686-pc-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll libraries:
$ rpm -qf /usr/i686-pc-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll mingw32-gcc-4.5.1-1.fc15.x86_64 $ i686-pc-mingw32-nm /usr/i686-pc-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll |grep Tls 6ced3d18 T _TlsAlloc@0 6ced3d28 T _TlsFree@4 6ced3d30 T _TlsGetValue@4 6ced3d40 T _TlsSetValue@8 6ced80e4 I __imp__TlsAlloc@0 6ced80e8 I __imp__TlsFree@4 6ced80ec I __imp__TlsGetValue@4 6ced80f0 I __imp__TlsSetValue@8
In my opinion gcc 4.4 automatically links against this library but gcc 4.5 doesn't (not sure why, yet).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #16 from Kalev Lember kalev@smartlink.ee 2010-09-07 09:38:55 EDT --- There's a number of interesting patches in tdm-gcc build http://downloads.sourceforge.net/tdm-gcc/gcc-4.5.1-tdmsrc-1.zip , I wonder if any of these might solve our problem.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #17 from Daniel Berrange berrange@redhat.com 2010-09-07 09:55:55 EDT --- The libgcceh.patch looks particularly interesting - it definitely touches the area which is causing us problems.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Erik van Pienbroek erik-fedora@vanpienbroek.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erik-fedora@vanpienbroek.nl
--- Comment #18 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2010-09-07 15:57:34 EDT --- mingw32-pixman is affected by this as well: http://koji.fedoraproject.org/koji/getfile?taskID=2452661&name=build.log
CCLD composite.exe /usr/lib/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_key_create': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:582: undefined reference to `TlsAlloc@0' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:589: undefined reference to `__mingwthr_key_dtor' /usr/lib/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_once': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:554: undefined reference to `InterlockedIncrement@4' /usr/lib/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_setspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `TlsSetValue@8' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `TlsSetValue@8' /usr/lib/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_getspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' /usr/lib/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_setspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `TlsSetValue@8' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:621: undefined reference to `TlsSetValue@8' /usr/lib/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_getspecific': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:613: undefined reference to `SetLastError@4' make[2]: Leaving directory `/builddir/build/BUILD/pixman-0.19.2/test' make[2]: *** [composite.exe] Error 1 make[1]: *** [all-recursive] Error 1
It's strange that a local build on my F14 environment compiles fine but a koji build for F15 as well as F14 fails
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Adam Tkac atkac@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |ASSIGNED
--- Comment #19 from Adam Tkac atkac@redhat.com 2010-09-08 05:30:48 EDT --- I've untagged mingw32-runtime-3.18-1.fc15 from F15 buildroot for now because it's impossible to build even gcc.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #20 from Adam Tkac atkac@redhat.com 2010-09-08 10:10:51 EDT --- (In reply to comment #17)
The libgcceh.patch looks particularly interesting - it definitely touches the area which is causing us problems.
This patch doesn't help. Also eh_shmem.patch, which looks interesting, doesn't help. In my opinion we should downgrade to gcc 4.4.4 before this problem gets fixed in 4.5 branch or try to use DWARF exception handling instead of SJLJ (not sure if it helps).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #21 from Daniel Berrange berrange@redhat.com 2010-09-08 10:17:05 EDT --- I tried rebuilding everything with DWARF instead of SJLJ and it didn't help:-( All that happened was this line
/usr/lib64/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-sjlj.o): In function `_gthread_key_create':
changed to
/usr/lib64/gcc/i686-pc-mingw32/4.5.1/libgcc_eh.a(unwind-dwarf.o): In function `_gthread_key_create':
and the particular undefined symbols were slightly different, but overall just as broken.
There are a fair few diffs in gcc 4.4.x vs 4.5.x that are related to MinGW platforms, focusing on adding support for Mingw64. I've been looking at diffs, but not identified a particular troublespot there yet.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
John Stebbins stebbins@jetheaddev.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stebbins@jetheaddev.com
--- Comment #22 from John Stebbins stebbins@jetheaddev.com 2010-09-11 11:59:49 EDT --- (In reply to comment #4)
mingw32-gcc doesn't appear to build against mingw32-runtime-3.18, see http://koji.fedoraproject.org/koji/getfile?taskID=2449090&name=build.log
Creating library file: .libs/libgfortran.dll.a/builddir/build/BUILD/gcc-4.5.1/build/./gcc/libgcc_eh.a(unwind-sjlj.o): In function `__gthread_key_create': /builddir/build/BUILD/gcc-4.5.1/build/i686-pc-mingw32/libgcc/../../../libgcc/../gcc/gthr-win32.h:582: undefined reference to `_TlsAlloc@0'
I ran across a what appears to be the same problem when compiling a library with mingw64 which is available here (which is also gcc-4.5) http://www.mail-archive.com/mingw@lists.fedoraproject.org/msg00135.html
After a little experimentation, I discovered that the code that provokes it is a function that uses varargs. e.g. int my_printf( char *fmt, ... ) { }
Removing the function allowed the link to succeed. Also, leave the function in and link with g++ instead of gcc succeeds.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #23 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2010-10-01 06:59:00 EDT --- Just to let you people know, I'm currently working on getting a combined win32/win64 toolchain operational based on the code from the mingw-w64 project. Perhaps we can aim to make this a Fedora 15 feature? More details coming soon to the fedora-mingw mailing list
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Thomas Sailer t.sailer@alumni.ethz.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |t.sailer@alumni.ethz.ch
--- Comment #24 from Thomas Sailer t.sailer@alumni.ethz.ch 2010-11-22 09:59:16 EST --- Any news on this issue?
Currently, we have binutils in F14 producing v2 relocs by default, but a runtime that doesn't understand v2 relocs and crashes
We should either, if updating to 3.18 is no option, patch v2 reloc capability into 3.15.2 from later versions, or hack binutils to default to v1 relocs.
Right now all users need to manually add --enable-runtime-pseudo-reloc-v1 to their linker command line or risk getting segfaulting programs.
See for example 654424.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #25 from Adam Tkac atkac@redhat.com 2010-11-22 10:36:59 EST --- (In reply to comment #24)
Any news on this issue?
Currently, we have binutils in F14 producing v2 relocs by default, but a runtime that doesn't understand v2 relocs and crashes
We should either, if updating to 3.18 is no option, patch v2 reloc capability into 3.15.2 from later versions, or hack binutils to default to v1 relocs.
It is currently not possible because 3.15.2 recompiled with gcc 4.5.X is broken. In my opinion the best solution, at least for now, is to revert gcc to 4.4.X. With this version everything works fine.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #26 from Thomas Sailer t.sailer@alumni.ethz.ch 2010-11-22 10:42:31 EST --- Could this be binutils related?
With current binutils I can't even compile the simple test program from 654424 without it crashing, with my private rebuild of mingw32-binutils-2.20.51.0.10-1.fc14.x86_64.rpm with --enable-runtime-pseudo-reloc-v1 it works for me.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #27 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2010-11-22 10:49:08 EST --- Instead of reverting to GCC 4.4 I would prefer if the gcc parameter '-Wl,--enable-runtime-pseudo-reloc-v1' would be added to the default LDFLAGS in mingw32-filesystem. That way we only have to rebuild the affected packages (AFAIK only boost is affected).
On the other hand, it's a bit strange that boost crashes while I don't have any problem with the other mingw32 packages in F14 (the whole GTK and Qt chains). Perhaps this only affects some C++ packages?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #28 from Kalev Lember kalev@smartlink.ee 2010-11-22 11:06:56 EST --- Thomas: Could you please try if F14 default binutils (2.20.1) work with --enable-auto-import? runtime-pseudo-reloc-v1 should already be the default in F14.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #29 from Thomas Sailer t.sailer@alumni.ethz.ch 2010-11-22 11:11:40 EST --- $ i686-pc-mingw32-g++ -O2 -g -pipe -Wall -fexceptions -mms-bitfields test.cpp -o test.exe -lboost_regex-gcc45-d-1_44 -lkernel32 -Wl,--enable-auto-import
$ wine test.exe Simple test
Works for me
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #30 from Kalev Lember kalev@smartlink.ee 2010-11-22 11:31:31 EST --- Okay, in that case I think we need to change binutils in F14 to default to enable-auto-import. Let me cook up a patch for that.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #31 from Kalev Lember kalev@smartlink.ee 2010-11-22 11:49:09 EST --- I built mingw32-binutils-2.20.1-2.fc14 with auto-import enabled as default, so hopefully the new build should work without having to pass any extra options on the command line: http://koji.fedoraproject.org/koji/buildinfo?buildID=205949
Can you test that please?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #32 from Thomas Sailer t.sailer@alumni.ethz.ch 2010-11-22 12:06:35 EST --- Works for me, thanks for resolving this quickly.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #33 from Fedora Update System updates@fedoraproject.org 2010-11-22 12:19:14 EST --- mingw32-binutils-2.20.1-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/mingw32-binutils-2.20.1-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #34 from Adam Tkac atkac@redhat.com 2010-11-23 10:41:58 EST --- Although new binutils fixes issues with C++ code, it doesn't fix issues written in comment #4 and comment #5.
In my opinion this bug should not be closed, yet. It seems the real problem lies somewhere in gcc.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #35 from Fedora Update System updates@fedoraproject.org 2010-12-01 17:00:38 EST --- mingw32-binutils-2.20.1-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Andrew Beekhof abeekhof@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |658833
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Andrew Beekhof abeekhof@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|658833 |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Andrew Beekhof abeekhof@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abeekhof@redhat.com
--- Comment #36 from Andrew Beekhof abeekhof@redhat.com 2010-12-29 06:08:44 EST --- FYI: Downgrading to gcc-4.4.2 was the only thing that worked for me.
Once I did that[1], I was able to rebuild much[2] of the mingw32 buildchain - including mingw32-runtime 3.18 and mingw32-binutils-2.20.1-2.
[1] And hacked mingw32-filesystem to temporarily provide mingw32(libstdc++-6.dll) so that I could install mingw32-pthreads so that I could install mingw32-gcc so that I could rebuild mingw32-pthreads to not need mingw32(libstdc++-6.dll). Sigh.
[2] Packages that built fine:
mingw32-filesystem mingw32-binutils mingw32-runtime mingw32-w32api mingw32-pthreads mingw32-gcc mingw32-bzip2 mingw32-dlfcn mingw32-expat mingw32-iconv mingw32-pcre mingw32-portablexdr mingw32-sigar mingw32-srvany mingw32-termcap mingw32-zlib mingw32-readline mingw32-gettext mingw32-libgpg-error mingw32-libxml2 mingw32-glib2 mingw32-libgcrypt mingw32-libxslt
Packages I'm still looking into:
mingw32-gnutls
../gl/.libs/libgnu.a(version-etc.o): In function `version_etc_va': /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:58: undefined reference to `_libintl_fprintf' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:65: undefined reference to `_libintl_gettext' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:65: undefined reference to `_libintl_fprintf' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:67: undefined reference to `_libintl_gettext' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:141: undefined reference to `_libintl_gettext' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:60: undefined reference to `_libintl_fprintf' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:141: undefined reference to `_libintl_vfprintf' collect2: ld returned 1 exit status
mingw32-boost
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_12xml_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_12xml_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_12xml_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_12xml_oarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_12xml_oarchiveEEEE12is_destroyedEv: symbol not found
...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #37 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2010-12-30 08:12:00 EST --- (In reply to comment #36)
Packages I'm still looking into:
mingw32-gnutls
../gl/.libs/libgnu.a(version-etc.o): In function `version_etc_va': /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:58: undefined reference to `_libintl_fprintf' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:65: undefined reference to `_libintl_gettext' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:65: undefined reference to `_libintl_fprintf' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:67: undefined reference to `_libintl_gettext' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:141: undefined reference to `_libintl_gettext' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:60: undefined reference to `_libintl_fprintf' /builddir/build/BUILD/gnutls-2.6.4/gl/version-etc.c:141: undefined reference to `_libintl_vfprintf' collect2: ld returned 1 exit status
What version of mingw32-gnutls did you use? I just tried to rebuild mingw32-gnutls-2.6.4-4.fc15 in a mock rawhide environment and it completed successfully
Also note that I'm about to announce all my work on a mixed win32/win64 compiler environment using the mingw-w64 toolchain. My goal is to get this in Fedora 15 (I plan to spend two full weeks on getting this done in week 2 and 3 of january).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #38 from Andrew Beekhof abeekhof@redhat.com 2011-01-01 05:52:00 EST --- (In reply to comment #37)
(In reply to comment #36)
Packages I'm still looking into:
mingw32-gnutls
What version of mingw32-gnutls did you use?
Hi Erik, it was a rebuild of the latest in F-14 - one of yours by the looks of it :-)
* Fri Oct 9 2009 Erik van Pienbroek epienbro@fedoraproject.org - 2.6.4-3
I just tried to rebuild mingw32-gnutls-2.6.4-4.fc15 in a mock rawhide environment and it completed successfully
For added complication I'm in a RHEL-6 environment. There may be a version issue with a linux package (same thing happened with mingw32-glib2), I've not looked very closely yet.
Also note that I'm about to announce all my work on a mixed win32/win64 compiler environment using the mingw-w64 toolchain. My goal is to get this in Fedora 15 (I plan to spend two full weeks on getting this done in week 2 and 3 of january).
Might be a fraction late for my personal deadlines - but very glad to hear that progress is being made :-)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #39 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2011-01-01 07:02:24 EST --- (In reply to comment #38)
(In reply to comment #37)
What version of mingw32-gnutls did you use?
Hi Erik, it was a rebuild of the latest in F-14 - one of yours by the looks of it :-)
Did you use the rawhide version of mingw32-gettext? If you used the rawhide version of mingw32-gettext in combination with the F-14 version of mingw32-gnutls then it's correct that you get a compile error. The rawhide version of mingw32-gettext contains a change which makes binaries have a soft-dependency on libintl-8.dll.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #40 from Andrew Beekhof abeekhof@redhat.com 2011-01-01 09:23:25 EST --- Everything was from F-14 or F-14 updates with only gcc and glib2 downgraded to their F-13 versions. Perhaps the version of gettext in rawhide has already made it into F-14 updates?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #41 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2011-01-01 09:35:58 EST --- That's very strange...the rawhide mingw32-gettext changes shouldn't have been applied to the F-14 branch. What is the exact package version of mingw32-gettext which you used? The package mingw32-gettext-0.17-13 contains the soft-dependency change, so anything earlier should be okay.
BTW, shouldn't we continue this discussion on the mingw@lists.fedoraproject.org mailing list or on IRC (FreeNode, #fedora-mingw) as we're getting kinda offtopic here?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #42 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2011-02-16 19:17:15 EST --- Due to the F15 mass-rebuild the mingw32-runtime 3.18 package got added back to the buildroot again causing new builds to fail (like http://koji.fedoraproject.org/koji/taskinfo?taskID=2845459 for example).
Is anybody actually planning to fix this issue or do we want to pull back the mingw32-runtime 3.18 package from the f15 and f16 buildroots again? I personally don't want to spend much time on the mingw.org toolchain as we're about to introduce the mingw-w64 toolchain in f16
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #43 from Adam Tkac atkac@redhat.com 2011-02-17 04:28:34 EST --- (In reply to comment #42)
Due to the F15 mass-rebuild the mingw32-runtime 3.18 package got added back to the buildroot again causing new builds to fail (like http://koji.fedoraproject.org/koji/taskinfo?taskID=2845459 for example).
Is anybody actually planning to fix this issue or do we want to pull back the mingw32-runtime 3.18 package from the f15 and f16 buildroots again? I personally don't want to spend much time on the mingw.org toolchain as we're about to introduce the mingw-w64 toolchain in f16
From my point of view I would also untag the latest mingw32-runtime build and
use the F13's one.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #44 from Daniel Berrange berrange@redhat.com 2011-02-17 05:59:02 EST --- I spent alot of time trying to get mingw32-runtime 3.18 working and failed. IMHO we should revert it and focus all efforts on mingw-w64
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #45 from Thomas Sailer t.sailer@alumni.ethz.ch 2011-02-17 06:02:17 EST --- It's a pity the w64 toolchain doesn't make it into F15, and since we failed in the past to get 3.18 working I'm also in favor of reverting for F15.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #46 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2011-02-17 06:10:12 EST --- I'm also +1 for reverting to the previous (working) mingw32-runtime. Adam, could you do this (as you've also done this the first time) ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #47 from Adam Tkac atkac@redhat.com 2011-02-18 03:31:36 EST --- (In reply to comment #46)
I'm also +1 for reverting to the previous (working) mingw32-runtime. Adam, could you do this (as you've also done this the first time) ?
I've submitted ticket to Fedora releng (https://fedorahosted.org/rel-eng/ticket/4448), they should untag the broken mingw32-runtime from dist-f15.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
--- Comment #48 from Kalev Lember kalev@smartlink.ee 2011-05-10 12:05:12 EDT --- I poked at this a bit and it looks like building mingw32-runtime without -fexceptions fixes the _gthread_key_create related linking errors described in comment #4 and comment #5.
I don't understand much how the threading during exception unwinding works and all the magic that's happening with __mingwthr_key_dtor. We should probably cook up a patch for upstream, but it should be done by someone who really understands what's going on here.
In any case, I'm going to build mingw32-runtime-3.18 for rawhide shortly. It would be great if someone else besides me could give it a try.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=629209
Kalev Lember kalev@smartlink.ee changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Version|14 |rawhide Fixed In Version| |mingw32-runtime-3.18-3.fc16 Resolution| |RAWHIDE AssignedTo|atkac@redhat.com |kalev@smartlink.ee Last Closed| |2011-05-10 18:37:18
--- Comment #49 from Kalev Lember kalev@smartlink.ee 2011-05-10 18:37:18 EDT --- The fixed build is mingw32-runtime-3.18-3.fc16. I also updated mingw32-w32api to 3.17 and rebuilt mingw32-binutils so that it now defaults to runtime pseudo-reloc v2 (the old mingw32-runtime only supported v1).
The toolchain appears to be working fine. Mingw32-gcc rebuilt successfully, and, what's best, the original problem from comment #1 is fixed: a freshly built vncviewer.exe from tigervnc-1.0.1 no longer crashes at startup.
Closing the ticket.
-
Red Hat Bugzilla