On 11/06/2013 12:19 PM, Laurent Bigonville wrote: > Le Wed, 06 Nov 2013 12:09:58 -0500, > Stephen Smalley <sds@xxxxxxxxxxxxx> a écrit : > >> On 11/06/2013 10:40 AM, Sven Vermeulen wrote: >>> On Mon, Nov 4, 2013 at 3:16 PM, Laurent Bigonville >>> <bigon@xxxxxxxxxx> wrote: >>>>> Yes we originally added the link for pthread_atfork, but have >>>>> replaced that with a GCC Equivalebt __selinux_atfork. >>>>> >>>>> Laurent, does debian not work without -lpthread? Gcc guys did >>>>> not want to require all apps that use libselinux to compile >>>>> against lpthread. >>>> >>>> I think it's the upgrade from a version of libselinux that was >>>> linking against -lpthread (2.1.13) to a version that doesn't that >>>> caused the problem (well this is my wild uninformed guess). >>>> >>>> The Debian bug >>>> is at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728529 >>>> >>>> This could probably be fixed in debian by rebuilding all the >>>> reverse dependencies of libselinux, but that will also affect >>>> Gentoo too (added Sven in CC), or the downstreams should carry the >>>> patch. >>>> >>>> I'm a bit lost with these pthread issues :/ >>> >>> Without linking to libpthread (bugs >>> https://bugs.gentoo.org/show_bug.cgi?id=473714 and >>> https://bugs.gentoo.org/show_bug.cgi?id=476866) we couldn't build >>> some of the tools that support SELinux (i.e. link with libselinux) >>> whereas, if we disable SELinux support, they do build properly >>> (busybox is the one most often found as it is used for our >>> initramfs building so generally one of the packages that is >>> immediately seen - others might exist like cryptsetup and such). >>> >>> If another fix or approach solves this I'm too fine with this. It is >>> just something I know less about on how to proceed (not my cup of >>> tea, so to speak). >> >> pthread calls from libselinux are supposed to be wrapped with the >> macros in libselinux/src/selinux_internal.h that conditionally expand >> to either a call to the libpthread function if the calling >> application links with libpthread already or to a trivial >> non-threaded implementation otherwise. That avoids requiring a >> libpthread dependency for everything that uses libselinux; you only >> need the pthread implementations when the application itself is >> multi-threaded. Apparently someone forgot to use this approach when >> they introduced usage of pthread_atfork() in libselinux and wrongly >> added libpthread as a dependency, but this has now been fixed in >> libselinux 2.2. >> >> Obviously you are free to restore it in your distro package but I >> don't think it is correct for upstream libselinux. > > But then that means my 2nd patch ([PATCH 2/2] src/libselinux.pc.in: Move -lpthread to Libs.private) > should still be applied (or should -lpthread completely removed from > the .pc file even for static linking?). I would think we could omit libpthread altogether from the .pc file, although I am not 100% certain of the implications. It wasn't added to it until after the pthread_atfork() change. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
