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