#982248 libsrtp2: FTBFS on hppa - LD_LIBRARY_PATH not set?

Package:
src:libsrtp2
Source:
libsrtp2
Submitter:
John David Anglin
Date:
2021-02-07 21:42:04 UTC
Severity:
normal
Tags:
#982248#5
Date:
2021-02-07 17:03:09 UTC
From:
To:
Dear Maintainer,

Build fails here:
+ ./rtpw -w /<<PKGBUILDDIR>>/test/words.txt -b Ky7cUDT2GnI0XKWYbXv9AYmqbcLsqzL9mvdN9t/G -a -e 128 -r 0.0.0.0 9999
./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&arch=hppa&ver=2.3.0-5&stamp=1612713361&raw=0

Regards,
Dave Anglin
#982248#10
Date:
2021-02-07 18:49:57 UTC
From:
To:
Hi Dave,

Quoting John David Anglin (2021-02-07 18:03:09)

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
#982248#17
Date:
2021-02-07 19:02:58 UTC
From:
To:
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
#982248#22
Date:
2021-02-07 19:20:42 UTC
From:
To:
Oh, there's nothing special about the handling of shared libraries on hppa-linux.  It uses the standard glibc
dynamic linker.

Regards,
Dave
#982248#27
Date:
2021-02-07 19:37:51 UTC
From:
To:
Quoting John David Anglin (2021-02-07 20:20:42)

I am aware of the LD_LIBRARY_PATH environment variable.

What I don't understand is why it is needed only on hppa.


 - Jonas
#982248#32
Date:
2021-02-07 21:30:31 UTC
From:
To:
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=/<<PKGBUILDDIR>>=.
-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
#982248#37
Date:
2021-02-07 21:38:52 UTC
From:
To:
The same error occurs on sparc64.

Regards,
Dave