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

[Yuriy M. Kaminskiy]

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.