Re: [libvirt] Mass rebuild report for August 29 2013
On 08/29/2013 11:38 AM, Erik van Pienbroek wrote:
This mass rebuild was done using winpthreads instead of the old pthreads-w32 implementation. In Fedora itself winpthreads isn't used by default yet, but it will be introduced in Fedora 20 once all build failures which are caused by it are resolved (if this takes too long the introduction of winpthreads in Fedora will have to be postponed until Fedora 21 which is scheduled for release in Q2 2014). The gcc package is still being built without --enable-threads=posix (thus support for C++11 std::thread is not enabled yet)
mingw-libvirt-1.1.1-1 Package owner: berrange Time to build: 6 minutes, 39 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130829/mingw-libvirt-1....
Also caused by winpthreads:
CCLD libvirt.la ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o): In function `virNetClientIOEventLoop': /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:1517: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:1524: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:1524: undefined reference to `pthread_sigmask' ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o): In function `virNetClientSetTLSSession': /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:785: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:792: undefined reference to `pthread_sigmask' ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o):/builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:809: more undefined references to `pthread_sigmask' follow collect2: error: ld returned 1 exit status
Hmm. The libvirt build for mingw explicitly wants to avoid pthread_*, and use native threading instead (at least we wanted to explicitly avoid the old pthreads-w32, and since we already have native thread support, we might as well use it instead of dragging in winpthreads). Probably a case of our configure checks not detecting the right situation once winpthreads are turned on. I'll see if we can get this fixed up for libvirt 1.1.2 (due real soon now), or if it will have to wait for 1.1.3 (a month out, but probably still in time to make it into F20). Is there an easy environment to set up (such as rawhide + a repo) for testing a mingw cross-build with winpthreads? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Eric Blake schreef op do 29-08-2013 om 14:07 [-0600]:
On 08/29/2013 11:38 AM, Erik van Pienbroek wrote:
This mass rebuild was done using winpthreads instead of the old pthreads-w32 implementation. In Fedora itself winpthreads isn't used by default yet, but it will be introduced in Fedora 20 once all build failures which are caused by it are resolved (if this takes too long the introduction of winpthreads in Fedora will have to be postponed until Fedora 21 which is scheduled for release in Q2 2014). The gcc package is still being built without --enable-threads=posix (thus support for C++11 std::thread is not enabled yet)
mingw-libvirt-1.1.1-1 Package owner: berrange Time to build: 6 minutes, 39 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130829/mingw-libvirt-1....
Also caused by winpthreads:
CCLD libvirt.la ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o): In function `virNetClientIOEventLoop': /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:1517: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:1524: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:1524: undefined reference to `pthread_sigmask' ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o): In function `virNetClientSetTLSSession': /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:785: undefined reference to `pthread_sigmask' /builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:792: undefined reference to `pthread_sigmask' ./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o):/builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:809: more undefined references to `pthread_sigmask' follow collect2: error: ld returned 1 exit status
Hmm. The libvirt build for mingw explicitly wants to avoid pthread_*, and use native threading instead (at least we wanted to explicitly avoid the old pthreads-w32, and since we already have native thread support, we might as well use it instead of dragging in winpthreads). Probably a case of our configure checks not detecting the right situation once winpthreads are turned on. I'll see if we can get this fixed up for libvirt 1.1.2 (due real soon now), or if it will have to wait for 1.1.3 (a month out, but probably still in time to make it into F20). Is there an easy environment to set up (such as rawhide + a repo) for testing a mingw cross-build with winpthreads?
Hi Eric, Some time ago I filed https://bugzilla.redhat.com/show_bug.cgi?id=969231 against the Fedora mingw-libvirt package for this issue. According to Daniel Berrange winpthreads isn't following the POSIX specifications as the symbol pthread_sigmask should be mentioned in signal.h while for winpthreads this symbol is currently only mentioned in pthread.h. Setting up an environment with Fedora MinGW + winpthreads requires some preparation (as I don't want to pollute rawhide yet). A recent rawhide environment should be enough as starting point. I just created some scratch builds which you can install directly with 'yum localinstall' to have a winpthreads-based mingw environment: http://koji.fedoraproject.org/koji/taskinfo?taskID=5871269 http://koji.fedoraproject.org/koji/taskinfo?taskID=5871279 Regards, Erik
On 08/29/2013 02:37 PM, Erik van Pienbroek wrote:
Eric Blake schreef op do 29-08-2013 om 14:07 [-0600]:
On 08/29/2013 11:38 AM, Erik van Pienbroek wrote:
This mass rebuild was done using winpthreads instead of the old pthreads-w32 implementation. In Fedora itself winpthreads isn't used by default yet, but it will be introduced in Fedora 20 once all build failures which are caused by it are resolved (if this takes too long the introduction of winpthreads in Fedora will have to be postponed until Fedora 21 which is scheduled for release in Q2 2014). The gcc package is still being built without --enable-threads=posix (thus support for C++11 std::thread is not enabled yet)
./.libs/libvirt_driver_remote.a(libvirt_net_rpc_client_la-virnetclient.o):/builddir/build/BUILD/libvirt-1.1.1/build_win32/src/../../src/rpc/virnetclient.c:809: more undefined references to `pthread_sigmask' follow collect2: error: ld returned 1 exit status
Hmm. The libvirt build for mingw explicitly wants to avoid pthread_*,
Hi Eric,
Some time ago I filed https://bugzilla.redhat.com/show_bug.cgi?id=969231 against the Fedora mingw-libvirt package for this issue. According to Daniel Berrange winpthreads isn't following the POSIX specifications as the symbol pthread_sigmask should be mentioned in signal.h while for winpthreads this symbol is currently only mentioned in pthread.h.
Setting up an environment with Fedora MinGW + winpthreads requires some preparation (as I don't want to pollute rawhide yet). A recent rawhide environment should be enough as starting point. I just created some scratch builds which you can install directly with 'yum localinstall' to have a winpthreads-based mingw environment:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5871269 http://koji.fedoraproject.org/koji/taskinfo?taskID=5871279
I've played with these in my rawhide VM (and fixed several other libvirt bugs in the meantime, so the time was not wasted :). I was unable to reproduce this particular failure, which may mean that the latest winpthreads has indeed fixed the issue. At any rate, I was pleased to note this in today's mass rebuild notice: mingw-libvirt-1.1.2-1 ** Package built successfully while it failed during the previous mass rebuild ** Time to build: 12 minutes, 1 second So at this point, I'll quit worrying further about the issue, and hope that your conversion to winpthreads goes successfully with the current state of libvirt. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Eric Blake schreef op di 17-09-2013 om 15:34 [-0600]:
I've played with these in my rawhide VM (and fixed several other libvirt bugs in the meantime, so the time was not wasted :). I was unable to reproduce this particular failure, which may mean that the latest winpthreads has indeed fixed the issue. At any rate, I was pleased to note this in today's mass rebuild notice:
mingw-libvirt-1.1.2-1 ** Package built successfully while it failed during the previous mass rebuild ** Time to build: 12 minutes, 1 second
So at this point, I'll quit worrying further about the issue, and hope that your conversion to winpthreads goes successfully with the current state of libvirt.
Hey Eric, We managed to get the issue resolved in upstream mingw-w64/winpthreads in commits http://sourceforge.net/p/mingw-w64/code/6218/ and http://sourceforge.net/p/mingw-w64/code/6227/ So libvirt builds fine now even when winpthreads is available. I haven't done any runtime tests yet, but I expect to introduce winpthreads (and rebuild all affected packages) tomorrow in Fedora 20 and rawhide. Regards, Erik
participants (2)
-
Eric Blake -
Erik van Pienbroek