Bug 629209

Adam, request co-maint on this package and then you will be able
to check in the update yourself.

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

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

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

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.

The 3.18 release changelog has this ominous, but rather uninformative, note:

2010-01-25  Kai Tietz  <kai.tietz>

        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

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

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.

.. and switch to mingw-w64 as soon as we can.

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.

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

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.

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

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

(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).

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.

The libgcceh.patch looks particularly interesting - it definitely touches the area which is causing us problems.

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

I've untagged mingw32-runtime-3.18-1.fc15 from F15 buildroot for now because it's impossible to build even gcc.

(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).

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.

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

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

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.

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

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.

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?

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.

$ 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

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.

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?

Works for me, thanks for resolving this quickly.

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

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.

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.

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

...

(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).

(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> - 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 :-)

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

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?

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.org mailing list or on IRC (FreeNode, #fedora-mingw) as we're getting kinda offtopic here?

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

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

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

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.

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

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

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.

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.