Re: [PATCH 1/2] Explicitly link libselinux against -lpthread

[Stephen Smalley <sds@tycho.nsa.gov>]

On 11/06/2013 12:19 PM, Laurent Bigonville wrote:
> Le Wed, 06 Nov 2013 12:09:58 -0500,
> Stephen Smalley <sds@tycho.nsa.gov> a écrit :
> 
>> On 11/06/2013 10:40 AM, Sven Vermeulen wrote:
>>> On Mon, Nov 4, 2013 at 3:16 PM, Laurent Bigonville
>>> <bigon@debian.org> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.