Bug 629209 - Update mingw32-runtime to 3.18
Summary: Update mingw32-runtime to 3.18
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mingw32-runtime
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-01 09:49 UTC by Adam Tkac
Modified: 2013-04-30 23:47 UTC (History)
11 users (show)

Fixed In Version: mingw32-runtime-3.18-3.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-10 22:37:18 UTC


Attachments (Terms of Use)

Description Adam Tkac 2010-09-01 09:49:05 UTC
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.

Comment 1 Richard W.M. Jones 2010-09-03 07:29:31 UTC
Adam, request co-maint on this package and then you will be able
to check in the update yourself.

Comment 2 Adam Tkac 2010-09-06 07:48:30 UTC
(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.

Comment 3 Fedora Update System 2010-09-06 07:57:16 UTC
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

Comment 4 Kalev Lember 2010-09-06 10:59:15 UTC
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

Comment 5 Richard W.M. Jones 2010-09-06 12:51:06 UTC
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.

Comment 6 Daniel Berrangé 2010-09-06 18:29:25 UTC
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/1146284e83aae91c

Comment 7 Fedora Update System 2010-09-07 06:46:37 UTC
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

Comment 8 Richard W.M. Jones 2010-09-07 11:12:31 UTC
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.

Comment 9 Richard W.M. Jones 2010-09-07 11:13:17 UTC
.. and switch to mingw-w64 as soon as we can.

Comment 10 Daniel Berrangé 2010-09-07 11:20:39 UTC
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.

Comment 11 Adam Tkac 2010-09-07 12:07:28 UTC
(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.

Comment 12 Adam Tkac 2010-09-07 12:16:43 UTC
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.

Comment 13 Richard W.M. Jones 2010-09-07 12:51:36 UTC
(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.

Comment 14 Daniel Berrangé 2010-09-07 13:03:12 UTC
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

Comment 15 Adam Tkac 2010-09-07 13:17:44 UTC
(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).

Comment 16 Kalev Lember 2010-09-07 13:38:55 UTC
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.

Comment 17 Daniel Berrangé 2010-09-07 13:55:55 UTC
The libgcceh.patch looks particularly interesting - it definitely touches the area which is causing us problems.

Comment 18 Erik van Pienbroek 2010-09-07 19:57:34 UTC
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

Comment 19 Adam Tkac 2010-09-08 09:30:48 UTC
I've untagged mingw32-runtime-3.18-1.fc15 from F15 buildroot for now because it's impossible to build even gcc.

Comment 20 Adam Tkac 2010-09-08 14:10:51 UTC
(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).

Comment 21 Daniel Berrangé 2010-09-08 14:17:05 UTC
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.

Comment 22 John Stebbins 2010-09-11 15:59:49 UTC
(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.

Comment 23 Erik van Pienbroek 2010-10-01 10:59:00 UTC
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

Comment 24 Thomas Sailer 2010-11-22 14:59:16 UTC
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.

Comment 25 Adam Tkac 2010-11-22 15:36:59 UTC
(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.

Comment 26 Thomas Sailer 2010-11-22 15:42:31 UTC
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.

Comment 27 Erik van Pienbroek 2010-11-22 15:49:08 UTC
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?

Comment 28 Kalev Lember 2010-11-22 16:06:56 UTC
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.

Comment 29 Thomas Sailer 2010-11-22 16:11:40 UTC
$ 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

Comment 30 Kalev Lember 2010-11-22 16:31:31 UTC
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.

Comment 31 Kalev Lember 2010-11-22 16:49:09 UTC
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?

Comment 32 Thomas Sailer 2010-11-22 17:06:35 UTC
Works for me, thanks for resolving this quickly.

Comment 33 Fedora Update System 2010-11-22 17:19:14 UTC
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

Comment 34 Adam Tkac 2010-11-23 15:41:58 UTC
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.

Comment 35 Fedora Update System 2010-12-01 22:00:38 UTC
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.

Comment 36 Andrew Beekhof 2010-12-29 11:08:44 UTC
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

...

Comment 37 Erik van Pienbroek 2010-12-30 13:12:00 UTC
(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).

Comment 38 Andrew Beekhof 2011-01-01 10:52:00 UTC
(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 :-)

Comment 39 Erik van Pienbroek 2011-01-01 12:02:24 UTC
(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.

Comment 40 Andrew Beekhof 2011-01-01 14:23:25 UTC
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?

Comment 41 Erik van Pienbroek 2011-01-01 14:35:58 UTC
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?

Comment 42 Erik van Pienbroek 2011-02-17 00:17:15 UTC
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

Comment 43 Adam Tkac 2011-02-17 09:28:34 UTC
(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.

Comment 44 Daniel Berrangé 2011-02-17 10:59:02 UTC
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

Comment 45 Thomas Sailer 2011-02-17 11:02:17 UTC
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.

Comment 46 Erik van Pienbroek 2011-02-17 11:10:12 UTC
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) ?

Comment 47 Adam Tkac 2011-02-18 08:31:36 UTC
(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.

Comment 48 Kalev Lember 2011-05-10 16:05:12 UTC
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.

Comment 49 Kalev Lember 2011-05-10 22:37:18 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.