Bug#794798: libnspr4-dev: pthread missing from pkg-config lib

[Peter Jones]

> Mike Hommey wrote:
> > On Thu, Aug 06, 2015 at 04:37:06PM -0500, D. Jared Dominguez wrote:
> >> On Thu, Aug 06, 2015 at 03:46:39PM -0500, Mike Hommey wrote:
> >> >On Thu, Aug 06, 2015 at 01:42:55PM -0500, Daniel Jared Dominguez wrote:
> >> >>Package: libnspr4-dev
> >> >>Version: 2:4.10.8-2
> >> >>Severity: important
> >> >>
> >> >>"pkg-config --libs nspr" returns:
> >> >>-lplds4 -lplc4 -lnspr4
> >> >>
> >> >>However, at least pthread is missing, which causes building with nspr4 and
> >> >>using pkg-config not to work right.
> >> >
> >> >You don't need to link against pthread to link against nspr.
> >>
> >> Well, it's what's causing this: http://paste.debian.net/289831/
> >>
> >> Particularly,
> >> """
> >> /usr/bin/gcc -g -O2 -fstack-protector-strong -Wformat
> >> -Werror=format-security  -Wall -Wsign-compare -Wno-unused-result
> >> -Wno-unused-function -std=gnu11 -fshort-wchar -fPIC -flto
> >> -fno-strict-aliasing -fno-merge-constants -D_GNU_SOURCE -DCONFIG_x86_64
> >> -I/«PKGBUILDDIR»/include     -I/usr/include/efivar -I/usr/include/nss
> >> -I/usr/include/nspr   -Wl,-z,relro    -D_FORTIFY_SOURCE=2 -o pesigcheck
> >> pesigcheck.o pesigcheck_context.o certdb.o cms_common.o content_info.o oid.o
> >> password.o signed_data.o signer_info.o wincert.o ucs2.o
> >> /«PKGBUILDDIR»/libdpe/libdpe.a  -lefivar -lnss3 -lnssutil3 -lsmime3 -lssl3
> >> -lplds4 -lplc4 -lnspr4 -lpopt /usr/bin/ld: /tmp/ccSnL8H8.ltrans1.ltrans.o:
> >> undefined reference to symbol 'pthread_rwlock_wrlock@@GLIBC_2.2.5'
> >> //lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
> >> collect2: error: ld returned 1 exit status
> >> """
> >>
> >> I see that this is what Fedora is doing:
> >> http://pkgs.fedoraproject.org/cgit/nspr.git/tree/nspr-config-pc.patch
> >>
> >> Also,
> >> $ ldd /usr/lib/x86_64-linux-gnu/libnspr4.so | grep pthread
> >>         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3111be4000)
> >>
> >> To me, that seems to be a pretty good indication that pthread is needed to link
> >> against nspr.
> >
> > To me, that seems to be a pretty good indication that one of those
> > object files is using pthread_rwlock_wrlock.
> >
> > The only reference to pthread_rwlock_wrlock in the nspr code base is in
> > a .c file, which means there is no way something #including nspr header
> > can inadvertently have a dependency on that symbol.
> 
> -lpthread -lrt -ldl (@OS_LIBS@) is certainly required for static linking 
> (and there are static libraries in libnspr-dev).
> 
> (However, I think the linked above fedora patch is also slightly wrong, 
> @OS_LIBS@ should be in Libs.private, not in Libs).
> 
> But I don't see -static in failed command above, so not sure why it 
> fails and if this is a same problem.

This doesn't have anything to do with -static, or with header files.
What's going on is that the dynamic section of libnspr4.so has a
dependency pointing to libpthread.so.0:

$ eu-readelf -d /usr/lib/x86_64-linux-gnu/libnspr4.so
Dynamic segment contains 32 entries:
 Addr: 0x000000000023ad98  Offset: 0x03ad98  Link to section: [ 4] '.dynstr'
  Type              Value
  NEEDED            Shared library: [libpthread.so.0]
  NEEDED            Shared library: [libdl.so.2]
  NEEDED            Shared library: [librt.so.1]
  NEEDED            Shared library: [libc.so.6]
  SONAME            Library soname: [libnspr4.so]
...

But the linker that gcc gets when it calls /usr/bin/ld defaults to
having the option flags "--no-add-needed --no-copy-dt-needed-entries"
set - as I understand this has been a deliberate feature, and library
packages are supposed to have been fixed to work with[0].  The result is
that programs or libraries linking against libnspr4.so needs to use
-lpthreads /as a result of linking against libnspr4.so/.

Which is to say, with recent linkers, you do have to link against
pthread to link against nspr.

The normal way to express this is to make the output of "pkg-config
--libs nspr" include "-lpthread".  (It also requires "-ldl", but in this
case the program consuming it already has that incidentally.)  Currently
on debian you get "-lplds4 -lplc4 -lnspr4", which will cause the error
mentioned in the original report.  I'm not sure about the distinction
between Libs: and Libs.private: in pkg-config, except that Libs-private:
doesn't seem to add things to "pkg-config --libs" output, so it probably
is not the right place.  Putting it in Libs: as fedora does results in
the correct behavior - so on Fedora the output is currently "-lplds4
-lplc4 -lnspr4 -lpthread -ldl", which allows programs using nspr to link
correctly without workarounds.

[0] https://wiki.debian.org/ToolChain/DSOLinking pretty much says this.

--
  Peter