Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?
On 2021-02-07 4:30 p.m., John David Anglin wrote: > On 2021-02-07 2:37 p.m., Jonas Smedegaard wrote: >> What I don't understand is why it is needed only on hppa. > I'm not sure. The test is linked against both libsrtp2.a and libsrtp2.so.1. The same error occurs on sparc64. Regards, Dave -- John David Anglin dave.ang...@bell.net
Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?
On 2021-02-07 2:37 p.m., Jonas Smedegaard wrote: > What I don't understand is why it is needed only on hppa. I'm not sure. The test is linked against both libsrtp2.a and libsrtp2.so.1. gcc -DHAVE_CONFIG_H -Icrypto/include -I./include -I./crypto/include -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -Wformat -Werror=format-security -D_REENTRANT -O4 -fexpensive-optimizations -funroll-loops -fPIC -I/usr/include/nss -I/usr/include/nspr -L. -o test/dtls_srtp_driver test/dtls_srtp_driver.c test/getopt_s.c test/util.c libsrtp2.a -lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 -lsrtp2 That's a bit unusual. Some reference must be being pulled from libsrtp2.so.1 as a result of the "-lsrtp2" in the command line. Would have to debug to find what it is. Dave -- John David Anglin dave.ang...@bell.net
Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?
Quoting John David Anglin (2021-02-07 20:20:42) > On 2021-02-07 2:02 p.m., John David Anglin wrote: > > On 2021-02-07 1:49 p.m., Jonas Smedegaard wrote: > >> My guess is that the hppa build daemon is setup differently than > >> other build daemons, or maybe the hppa hardware need some special > >> magic to register shared objects. > > One way is to use the environment variable LD_LIBRARY_PATH. Many > > packages use it so that ld.so finds libraries that haven't been > > installed in the standard system locations. If you don't set it, it > > is possible that the installed system version is used. > Oh, there's nothing special about the handling of shared libraries on > hppa-linux. It uses the standard glibc dynamic linker. I am aware of the LD_LIBRARY_PATH environment variable. What I don't understand is why it is needed only on hppa. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?
On 2021-02-07 2:02 p.m., John David Anglin wrote: > On 2021-02-07 1:49 p.m., Jonas Smedegaard wrote: >> My guess is that the hppa build daemon is setup differently than other >> build daemons, or maybe the hppa hardware need some special magic to >> register shared objects. > One way is to use the environment variable LD_LIBRARY_PATH. Many packages > use it so that ld.so finds libraries that > haven't been installed in the standard system locations. If you don't set > it, it is possible that the installed system version is used. Oh, there's nothing special about the handling of shared libraries on hppa-linux. It uses the standard glibc dynamic linker. Regards, Dave -- John David Anglin dave.ang...@bell.net
Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?
On 2021-02-07 1:49 p.m., Jonas Smedegaard wrote: > My guess is that the hppa build daemon is setup differently than other > build daemons, or maybe the hppa hardware need some special magic to > register shared objects. One way is to use the environment variable LD_LIBRARY_PATH. Many packages use it so that ld.so finds libraries that haven't been installed in the standard system locations. If you don't set it, it is possible that the installed system version is used. Dave -- John David Anglin dave.ang...@bell.net
Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?
Control: tags -1 +help Hi Dave, Quoting John David Anglin (2021-02-07 18:03:09) > Source: libsrtp2 > Version: 2.3.0-5 > Severity: normal > > Dear Maintainer, > > Build fails here: > + ./rtpw -w /<>/test/words.txt -b > Ky7cUDT2GnI0XKWYbXv9AYmqbcLsqzL9mvdN9t/G -a -e 128 -r 0.0.0.0 > ./rtpw: error while loading shared libraries: libsrtp2.so.1: cannot open > shared object file: No such file or directory > > Full log is here: > https://buildd.debian.org/status/fetch.php?pkg=libsrtp2=hppa=2.3.0-5=1612713361=0 Thans for reporting this. Sorry, I am clueless as to why it fails - according to that build log, libsrtp2.so.1 _did_ get compiled (which to me indicates this is not an architecture-specific build failure) and testsuite succeeds on other architectures (which to me indicates this is not a failure in the the way the testsuite is executed). My guess is that the hppa build daemon is setup differently than other build daemons, or maybe the hppa hardware need some special magic to register shared objects. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#982248: libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?
Source: libsrtp2 Version: 2.3.0-5 Severity: normal Dear Maintainer, Build fails here: + ./rtpw -w /<>/test/words.txt -b Ky7cUDT2GnI0XKWYbXv9AYmqbcLsqzL9mvdN9t/G -a -e 128 -r 0.0.0.0 ./rtpw: error while loading shared libraries: libsrtp2.so.1: cannot open shared object file: No such file or directory Full log is here: https://buildd.debian.org/status/fetch.php?pkg=libsrtp2=hppa=2.3.0-5=1612713361=0 Regards, Dave Anglin -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 5.10.13+ (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
