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

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

[Laurent Bigonville]

From: Laurent Bigonville <bigon@bigon.be>

libselinux is using pthread functions internally without explicitly
linking against it.

If the executable is itself not linked against libpthread, this could
lead to some weird ld.so assertions, see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728529
---
 libselinux/src/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 02dd829..2a79b27 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -114,7 +114,7 @@ $(LIBA): $(OBJS)
 	$(RANLIB) $@
 
 $(LIBSO): $(LOBJS)
-	$(CC) $(CFLAGS) -shared -o $@ $^ -lpcre -ldl $(LDFLAGS) -L$(LIBDIR) -Wl,-soname,$(LIBSO),-z,defs,-z,relro
+	$(CC) $(CFLAGS) -shared -o $@ $^ -lpcre -lpthread -ldl $(LDFLAGS) -L$(LIBDIR) -Wl,-soname,$(LIBSO),-z,defs,-z,relro
 	ln -sf $@ $(TARGET) 
 
 $(LIBPC): $(LIBPC).in ../VERSION
-- 
1.8.4.2


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

[PATCH 2/2] src/libselinux.pc.in: Move -lpthread to Libs.private

[Laurent Bigonville]

From: Laurent Bigonville <bigon@bigon.be>

Move -lpthread to Libs.private as libselinux is not exposing any of its
API
---
 libselinux/src/libselinux.pc.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libselinux/src/libselinux.pc.in b/libselinux/src/libselinux.pc.in
index 2bd3c0e..f453c8f 100644
--- a/libselinux/src/libselinux.pc.in
+++ b/libselinux/src/libselinux.pc.in
@@ -8,5 +8,6 @@ Description: SELinux utility library
 Version: @VERSION@
 URL: http://userspace.selinuxproject.org/
 Requires.private: libsepol libpcre
-Libs: -L${libdir} -lselinux -lpthread
+Libs: -L${libdir} -lselinux
+Libs.private: -lpthread
 Cflags: -I${includedir}
-- 
1.8.4.2


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

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

[Stephen Smalley]

On 11/02/2013 07:13 PM, Laurent Bigonville wrote:
> From: Laurent Bigonville <bigon@bigon.be>
> 
> libselinux is using pthread functions internally without explicitly
> linking against it.
> 
> If the executable is itself not linked against libpthread, this could
> lead to some weird ld.so assertions, see:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728529

This seems to effectively revert a portion of:
commit c32da69e016061c1a06ec08298aae8c995fbea31
Author: Dan Walsh <dwalsh@redhat.com>
Date:   Wed Oct 9 16:27:43 2013 -0400

    Fixes for procattr calls to handle cache properly.

    We were asked not to link to libpthread but to use gcc internals.
    We were not handling properly the fact that a cache was UNSET, and this
    patch fixes this.

Can the two of you work out a proper fix that works for you both?

> ---
>  libselinux/src/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
> index 02dd829..2a79b27 100644
> --- a/libselinux/src/Makefile
> +++ b/libselinux/src/Makefile
> @@ -114,7 +114,7 @@ $(LIBA): $(OBJS)
>  	$(RANLIB) $@
>  
>  $(LIBSO): $(LOBJS)
> -	$(CC) $(CFLAGS) -shared -o $@ $^ -lpcre -ldl $(LDFLAGS) -L$(LIBDIR) -Wl,-soname,$(LIBSO),-z,defs,-z,relro
> +	$(CC) $(CFLAGS) -shared -o $@ $^ -lpcre -lpthread -ldl $(LDFLAGS) -L$(LIBDIR) -Wl,-soname,$(LIBSO),-z,defs,-z,relro
>  	ln -sf $@ $(TARGET) 
>  
>  $(LIBPC): $(LIBPC).in ../VERSION
> 


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

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

[Stephen Smalley]

On 11/04/2013 08:09 AM, Stephen Smalley wrote:
> On 11/02/2013 07:13 PM, Laurent Bigonville wrote:
>> From: Laurent Bigonville <bigon@bigon.be>
>>
>> libselinux is using pthread functions internally without explicitly
>> linking against it.
>>
>> If the executable is itself not linked against libpthread, this could
>> lead to some weird ld.so assertions, see:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728529
> 
> This seems to effectively revert a portion of:
> commit c32da69e016061c1a06ec08298aae8c995fbea31
> Author: Dan Walsh <dwalsh@redhat.com>
> Date:   Wed Oct 9 16:27:43 2013 -0400
> 
>     Fixes for procattr calls to handle cache properly.
> 
>     We were asked not to link to libpthread but to use gcc internals.
>     We were not handling properly the fact that a cache was UNSET, and this
>     patch fixes this.
> 
> Can the two of you work out a proper fix that works for you both?

Also, at least in the original of pthread_once, it was made a weak
binding on purpose to avoid requiring use of libpthread, switching the
implementation between a pthread-based one and a non-thread-safe
implementation depending on whether the caller links with libpthread.
So having libselinux link directly to libpthread seems to defeat the
purpose of that approach.



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

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

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/04/2013 08:18 AM, Stephen Smalley wrote:
> On 11/04/2013 08:09 AM, Stephen Smalley wrote:
>> On 11/02/2013 07:13 PM, Laurent Bigonville wrote:
>>> From: Laurent Bigonville <bigon@bigon.be>
>>> 
>>> libselinux is using pthread functions internally without explicitly 
>>> linking against it.
>>> 
>>> If the executable is itself not linked against libpthread, this could 
>>> lead to some weird ld.so assertions, see: 
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728529
>> 
>> This seems to effectively revert a portion of: commit
>> c32da69e016061c1a06ec08298aae8c995fbea31 Author: Dan Walsh
>> <dwalsh@redhat.com> Date:   Wed Oct 9 16:27:43 2013 -0400
>> 
>> Fixes for procattr calls to handle cache properly.
>> 
>> We were asked not to link to libpthread but to use gcc internals. We were
>> not handling properly the fact that a cache was UNSET, and this patch
>> fixes this.
>> 
>> Can the two of you work out a proper fix that works for you both?
> 
> Also, at least in the original of pthread_once, it was made a weak binding
> on purpose to avoid requiring use of libpthread, switching the 
> implementation between a pthread-based one and a non-thread-safe 
> implementation depending on whether the caller links with libpthread. So
> having libselinux link directly to libpthread seems to defeat the purpose
> of that approach.
> 
> 
> 
> -- 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.
> 
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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEUEARECAAYFAlJ3qDUACgkQrlYvE4MpobNPtgCcDKOA5WLeF9oV0oAP7uun5Mpo
rh8AmIn8pgwqO4bV0J7ooxXRllpBdaI=
=3Ljj
-----END PGP SIGNATURE-----

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

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

[Laurent Bigonville]

Le Mon, 04 Nov 2013 08:59:17 -0500,
Daniel J Walsh <dwalsh@redhat.com> a écrit :

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/04/2013 08:18 AM, Stephen Smalley wrote:
> > On 11/04/2013 08:09 AM, Stephen Smalley wrote:
> >> On 11/02/2013 07:13 PM, Laurent Bigonville wrote:
> >>> From: Laurent Bigonville <bigon@bigon.be>
> >>> 
> >>> libselinux is using pthread functions internally without
> >>> explicitly linking against it.
> >>> 
> >>> If the executable is itself not linked against libpthread, this
> >>> could lead to some weird ld.so assertions, see: 
> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728529
> >> 
> >> This seems to effectively revert a portion of: commit
> >> c32da69e016061c1a06ec08298aae8c995fbea31 Author: Dan Walsh
> >> <dwalsh@redhat.com> Date:   Wed Oct 9 16:27:43 2013 -0400
> >> 
> >> Fixes for procattr calls to handle cache properly.
> >> 
> >> We were asked not to link to libpthread but to use gcc internals.
> >> We were not handling properly the fact that a cache was UNSET, and
> >> this patch fixes this.
> >> 
> >> Can the two of you work out a proper fix that works for you both?
> > 
> > Also, at least in the original of pthread_once, it was made a weak
> > binding on purpose to avoid requiring use of libpthread, switching
> > the implementation between a pthread-based one and a
> > non-thread-safe implementation depending on whether the caller
> > links with libpthread. So having libselinux link directly to
> > libpthread seems to defeat the purpose of that approach.
> > 
> > 
> > 
> > -- 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.
> > 
> 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 :/


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

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

[Sven Vermeulen]

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

Wkr,
  Sven Vermeulen

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

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

[Stephen Smalley]

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.






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

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

[Laurent Bigonville]

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


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

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

[Stephen Smalley]

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.

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

[Stephen Smalley]

On 11/06/2013 12:35 PM, Stephen Smalley wrote:
> 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.

I have removed -lpthread from libselinux.pc.in and pushed this as
libselinux-2.2.1.



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