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

[Mike Hommey]

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.

Mike