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.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to