[email protected] wrote: > 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=498616 > > > > > > --- Comment #2 from Erik van Pienbroek <[email protected]> > 2009-05-20 11:51:53 EDT --- > 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?
agree. -- Levente "Si vis pacem para bellum!" _______________________________________________ fedora-mingw mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
