Created attachment 342094 [details] Libtool file which points to libpthreadGC2.a When compiling applications or libraries which depend on mingw32-pthread, the compilation always fails with a linker error: $ cat test.c int main(int argc, char **argv) { return 0; } $ i686-pc-mingw32-gcc test.c -o test.exe -lpthread /usr/lib64/gcc/i686-pc-mingw32/4.4.0/../../../../i686-pc-mingw32/bin/ld: cannot find -lpthread collect2: ld returned 1 exit status This is caused by the fact that only libpthreadGC2.a and libpthreadGCE2.a exist in the mingw32-pthread package. There are multiple solutions to fix this problem: - Rename one of the two .a files to libpthread.a - Create a .la file which points libtool to one of the .a files (file attached) Note: The second solution only works for libtool based projects. Does anyone know what the actual difference is between the two .a files ?
Created attachment 342095 [details] Libtool file which points to libpthreadGC2.a Just noticed I published an old version of the libpthread.la file (which still contained some bits from pixman). This is a cleaned up version
According to the README of pthreads-w32 this is the difference between the two .dll files: pthreadGC2.dll : No exception handling (uses setjmp/longjmp) pthreadGCE2.dll: C++ Exception handling Here's a snippet from the README file: There seems to be more opinion in favour of using the standard C version of the library (no EH) with C++ applications for the reason that this appears to be the assumption commercial pthreads implementations make. Therefore, if you use an EH version of pthreads-win32 then you may be under the illusion that your application will be portable, when in fact it is likely to behave differently when linked with other pthreads libraries. Therefore I'm proposing we create a symlink %{_mingw32_libdir}/libpthreadGC2.a -> %{_mingw32_libdir}/libpthread.a. The filename 'pthreadGC2.dll' is referenced in the libpthreadGC2.a file itself, so a symlink shouldn't cause any side-effects. The libtool solution as proposed earlier can be dropped. If libraries really want to make use of pthreadGCE2.dll (C++ EH) then they need to patch their build scripts so that they use '-lpthreadGCE2' instead of '-lpthread'. Any objections?
As long as we do *not* add mingw-pthreads as a RPM install dependenacy of mingw-gcc this ought to be reasonably safe. If we had mingw-pthreads install by default, then other packages build may accidentally decide to use pthreads instead of using the native Win32 threads next time they get rebuilt.
mingw32-pthreads-2.8.0-8.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/mingw32-pthreads-2.8.0-8.fc11
mingw32-pthreads-2.8.0-8.fc11 has been pushed to the Fedora 11 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-pthreads'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-5391
mingw32-pthreads-2.8.0-8.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.