This question already has answers here:
Build OpenSSL with RPATH?
(2 answers)
How to compile OpenSSL with relative rpath
(5 answers)
Closed 4 years ago.
I have different openssl versions on my system and I don't want to install the most current openssl version into the system location - e.q. /usr/bin/openssl.
Now, when I compile openssl then I get this running ldd:
root => ldd /FaF/openssl/bin/openssl
linux-vdso.so.1 (0x00007ffe60d92000)
--> libssl.so.1.1 => not found
--> libcrypto.so.1.1 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007facf337b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007facf315e000)
libc.so.6 => /lib64/libc.so.6 (0x00007facf2dbd000)
/lib64/ld-linux-x86-64.so.2 (0x00007facf357f000)
I refer to libssl.so.1.1 and libcrypto.so.1.1 which are not found and this is OK that far.
Running ldd with preceded LD_LIBRARY_PATH works:
root => LD_LIBRARY_PATH=/FaF/openssl/lib/ ldd /FaF/openssl/bin/openssl
linux-vdso.so.1 (0x00007fff221a1000)
libssl.so.1.1 => /FaF/openssl/lib/libssl.so.1.1 (0x00007f45f842a000)
libcrypto.so.1.1 => /FaF/openssl/lib/libcrypto.so.1.1 (0x00007f45f7f9a000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f45f7d96000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f45f7b79000)
libc.so.6 => /lib64/libc.so.6 (0x00007f45f77d8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f45f869b000)
/FaF/openssl/lib is the directory where the correct libraries are.
I have now these possible solutions:
Adding /FaF/openssl/lib to /etc/ld.so.conf and running ldconfig - This is not really an option because it may break the system version of openssl.
As I did in the above example I can precede each time I need opensslwith LD_LIBRARY_PATH=/FaF/openssl/lib/ - not really a good option and it isn't always possible.
I can link the path with --rpath=/FaF/openssl/lib into openssl.
My question:
For the moment I didn't figure out how to set --rpath=/FaF/openssl/lib in the configure command which generates openssl. Can somebody provide me this information?
I tried setting LD_LIBRARY_PATH and LDFLAGS but nothing works.
I prefer a solution which is hard-coded into openssl so there are not other settings required.
OK. Here is the - very simple - way how to solve it according to 3) from my question.
I ran ./config -h and got this output:
root => ./config -h
Usage: config [options]
-d Build with debugging when possible.
-t Test mode, do not run the Configure perl script.
-v Verbose mode, show the exact Configure call that is being made.
-h This help.
Any other text will be passed to the Configure perl script.
See INSTALL for instructions.
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
The text Any other text will be passed to the Configure perl script. says it all.
I just added the --rpath at the end to the config command which looks now like this:
./config --prefix=/FaF/openssl threads shared -Wl,--rpath=/FaF/openssl/lib
Related
I looked for similar post on this topic but none the solutions work for me. I am trying to build a small program using openssl.
/mnt/sda1/openssl$ gcc tstsvr.c -I/mnt/sda1/openssl/include -L/mnt/sda1/openssl -lcrypto -lssl
When I try to run it:
$ sudo ./a.out
./a.out: error while loading shared libraries: libcrypto.so.81.1.1: cannot open shared object file: No such file or directory
But:
$ ldd a.out
linux-vdso.so.1 (0x00007fff23fe6000)
libcrypto.so.81.1.1 => /mnt/sda1/openssl/libcrypto.so.81.1.1 (0x00007f82f1db9000)
libssl.so.81.1.1 => /mnt/sda1/openssl/libssl.so.81.1.1 (0x00007f82f1d1e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f82f1b1a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f82f1b14000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f82f1af1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f82f20ad000)
Format looks fine (inside /mnt/sda1/openssl):
$ file a.out
a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=760dc5f7be4f51f598bab38a0b1eab1a42ef8a68, for GNU/Linux 3.2.0, not stripped
$ file libcrypto.so.81.1.1
libcrypto.so.81.1.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=404d1e7ed143383801efbb10ed7914f2cd0858d4, not stripped
$ ldd libcrypto.so.81.1.1
linux-vdso.so.1 (0x00007ffc44b5a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1083a8c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1083a69000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1083877000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1083d93000)
Just to make sure, I added path to LD_LIBRARY_PATH as well. Even ran sudo ldconfig. Neither made any difference.
What else can I try?
Per sudoers(5):
By default, the env_reset flag is enabled. This causes commands to be executed with a new, minimal environment.
...
Note that the dynamic linker on most operating systems will remove variables that can control dynamic linking from the environment of set-user-ID executables, including sudo. Depending on the operating system this may include RLD*, DYLD, LD_, LDR_*, LIBPATH, SHLIB_PATH, and others. These type of variables are removed from the environment before sudo even begins execution and, as such, it is not possible for sudo to preserve them.
Your easiest option is probably to do:
sudo LD_LIBRARY_PATH=/mnt/sda1/openssl ./a.out
On Ubuntu 18.04 with apt install I installed libssl1.0.0 and libssl1.0-dev.
The following shared objects are available:
/usr/lib/x86_64-linux-gnu/libssl.so
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
/usr/lib/x86_64-linux-gnu/libcrypto.so
Set the variable LD_LIBRARY_PATH with the previous path:
$ echo $LD_LIBRARY_PATH
/usr/lib/x86_64-linux-gnu
Created the following symbolic links:
ln -s /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 /usr/lib/x86_64-linux-gnu/libssl.so.10
ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 /usr/lib/x86_64-linux-gnu/libcrypto.so.10
Now this is what I have:
$ file /usr/lib/x86_64-linux-gnu/libssl.so.10
/usr/lib/x86_64-linux-gnu/libssl.so.10: symbolic link to /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
$ ldd /usr/lib/x86_64-linux-gnu/libssl.so.10
linux-vdso.so.1 (0x00007ffeeaddb000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f28054fc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f280510b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2804f07000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2805ba7000)
$ file /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0d054641049b9747c05d030262295dfdfdd3055d, stripped
$ ldd /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
linux-vdso.so.1 (0x00007ffff3971000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f446f2b1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f446eec0000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f446ecbc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f446f95c000)
So, at this point the dependencies for the library I will use are met.
When I try to validate that, I get issues such as version `libssl.so.10' not found.
$ file libpjsua2.so
libpjsua2.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=9481ccc9a0bbfe937ebb1dbc40002af55c2b424c, not stripped
$ ldd libpjsua2.so
./libpjsua2.so: /usr/lib/x86_64-linux-gnu/libssl.so.10: version `libssl.so.10' not found (required by ./libpjsua2.so)
./libpjsua2.so: /usr/lib/x86_64-linux-gnu/libcrypto.so.10: version `OPENSSL_1.0.1_EC' not found (required by ./libpjsua2.so)
./libpjsua2.so: /usr/lib/x86_64-linux-gnu/libcrypto.so.10: version `libcrypto.so.10' not found (required by ./libpjsua2.so)
linux-vdso.so.1 (0x00007ffc83691000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0d98395000)
libssl.so.10 => /usr/lib/x86_64-linux-gnu/libssl.so.10 (0x00007f0d9812d000)
libcrypto.so.10 => /usr/lib/x86_64-linux-gnu/libcrypto.so.10 (0x00007f0d97cea000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0d97ae2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0d978c3000)
libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f0d975bc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0d9721e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0d97006000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0d96c15000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0d98d91000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0d96a11000)
I would like to highlight that appears somehow it's able to resolve some .so:
libssl.so.10 => /usr/lib/x86_64-linux-gnu/libssl.so.10 (0x00007f0d9812d000)
libcrypto.so.10 => /usr/lib/x86_64-linux-gnu/libcrypto.so.10 (0x00007f0d97cea000)
There is a way for me to fix this? So libpjsua2.so is usable.
The shared library libpjsua2.so is designed for the version of OpenSSL shipped by Red Hat, CentOS, or Fedora, while you're trying to use a version built for Ubuntu. This won't work because the SONAME is different, as well as the symbol versioning.
There isn't any way to make this work, so you'll either need to use a shared library compiled for an Ubuntu (or Debian) system or run your program on the system the shared library was compiled for. Note that both Debian and Ubuntu ship a package called libpjsua2, so installing that may meet your needs.
You could theoretically copy the relevant OpenSSL version from the intended operating system, but doing so will likely involve a bunch of other broken shared libraries, and you will probably not be happy with the result.
I need to build libldap under linux (and windows, but that's a different story).
When I do
./configure --prefix="$OPENLDAP_BUILD_PATH" --disable-slapd
make
make install
make clean
I get with ldd that libldap is linked with system libraries libssl.so and libcrypto.so. And what I need is to link it with my custom builds of this libraries.
I also tried this:
OPENLDAP2_BUILD_PATH="$BUILD_PATH/openldap2"
mkdir "$OPENLDAP2_BUILD_PATH"
OPENSSL_DEPENDENCY_PATH="$BUILD_PATH/openssl"
LD_LIBRARY_PATH="$OPENSSL_DEPENDENCY_PATH/lib:$LD_LIBRARY_PATH"
CPPFLAGS="-l$OPENSSL_DEPENDENCY_PATH/include/openssl"
LDFLAGS="-L$OPENSSL_DEPENDENCY_PATH/lib"
./configure --prefix="$OPENLDAP2_BUILD_PATH" --disable-slapd
make
make install
make clean
With no success either.
ldd libldap.so shows this:
linux-vdso.so.1 => (0x00007ffc91923000)
liblber-2.4.so.2 => /home/me/Work-U14/proj/shared/BUILD/openldap2/lib/liblber-2.4.so.2 (0x00007ff0ef638000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007ff0ef3f8000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007ff0ef198000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007ff0eedbc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff0ee9f4000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff0ee7ef000)
/lib64/ld-linux-x86-64.so.2 (0x000056386adf5000)
Found that below could work:
export LDFLAGS="-L/your/dir/to/openssl/lib"
export CPPFLAGS="-I/your/dir/to/openssl/include"
./configure ...
could work, the include path is:
-I/your/dir/to/openssl/include NOT
-I/your/dir/to/openssl/include/openssl
which the .h head files are all in the sub openssl dir under include,
the key point is get rid of the openssl dir under include dir, which by default for other packages we have to add this sub-directory under include, e.g. for apr, you have to make it as: -I/your/dir/to/apr/include/apr-1.
It's not a good solution, but a well-enough workaround for me.
I've written build.sh as follows:
#!/bin/sh
if [ -z "$BUILD_PATH" ]
then
echo "Variable BUILD_PATH isn't specified!"
exit
fi
OPENLDAP2_BUILD_PATH="$BUILD_PATH/openldap2"
export MY_OPENSSL_ROOT="$BUILD_PATH/openssl"
./configure --prefix=$OPENLDAP2_BUILD_PATH --disable-slapd >/home/sherst/Desktop/configure_log.openldap2 2>&1
make >/home/sherst/Desktop/make_log.openldap2 2>&1
make install >/home/sherst/Desktop/make_install_log.openldap2 2>&1
I've patched configure file as such:
LINE 15485
LIBS="-Wl,-rpath=$ORIGIN/ -L. -lssl -lcrypto $LIBS"
LINE 15582
TLS_LIBS="-Wl,-rpath=$MY_OPENSSL_ROOT/lib -L$MY_OPENSSL_ROOT/lib -lssl -lcrypto -lRSAglue -lrsaref"
LINE 15584
TLS_LIBS="-Wl,-rpath=$MY_OPENSSL_ROOT/lib -L$MY_OPENSSL_ROOT/lib -lssl -lcrypto"
In such way (I'm quite sure that it's very crude and overabundant) I've achieved that ldd shows links to my openssl libs. TO hard code them is a bad idea, but when, in distro, there will be no such paths, I expect ld to find them in local dir, where we plan to put them.
openldap faq says this should be achieved ain such way:
env CPPFLAGS=-I/path/to/openssl/include \
LDFLAGS=-L/path/to/openssl/lib-dir \
configure --with-tls ...
But that didn't work for me (perhaps, I did it wrong).
I found info how to add rpath here:
https://www.openldap.org/doc/admin24/install.html
Simply pass it to configure script:
/configure --enable-wrappers \
CPPFLAGS="-I/usr/local/include" \
LDFLAGS="-L/usr/local/lib -Wl,-rpath,/usr/local/lib"
This is a more general question. I know windows DLL's can have a resource file set up with the dll version information, but I'm wondering how to do the same for linux shared objects.
The problem I'm encountering is actually when running just about anything at the terminal, I get a message about libz.so.1 version information not being available. This is due to an application being present with its own version of libz that I've compiled. The library is actually libz.so.1.2.3 and the same version exists in /lib. The files are actually the SAME version of the library, but one of them (which I compiled) says it's missing version information.
So, that leads me to wonder how to actually include the version information in the binary rather than just in the file name. It would be ideal if there's a solution like
./configure .... some_version_option=1.2.3
If I use the working version of the library:
ldd /usr/bin/git
linux-vdso.so.1 => (0x00007fffdfbff000)
libz.so.1 => /lib64/libz.so.1 (0x00007f3797fa7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c56000000)
libc.so.6 => /lib64/libc.so.6 (0x0000003c55c00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003c55400000)
If I use the version I compiled:
ldd /usr/bin/git
/usr/bin/git: libz.so.1: no version information available (required by /usr/bin/git)
linux-vdso.so.1 => (0x00007fff872b1000)
libz.so.1 (0x00007f83c9270000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c56000000)
libc.so.6 => /lib64/libc.so.6 (0x0000003c55c00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003c55400000)
You need to pass the library's symbol version map file with -Wl,--version-script <file.map>. The map file should be included in the library source.
I'm trying to compile samtools on a Solaris server where I do not have root. Samtools depends on zlib. The system zlib on this machine is not compiled with large file support, so compiling samtools against this version has the expected effect: samtools only handle small files. I need it to be able to handle large files. Luckily, there is a version of zlib compiled by the admin in /usr/local/apps/zlib-1.2.5/ with large file support. I can compile against this by adding -R /usr/local/apps/zlib-1.2.5/lib to CFLAGS, but this seems not to work. The symptoms are as follows:
When I try to run samtools, it crashes with this error:
ld.so.1: samtools: fatal: relocation error: file samtools: symbol gzopen64: referenced symbol not found
If I add /usr/local/apps/zlib-1.2.5/ to LD_LIBRARY_PATH, then samtools works fine.
Analyzing samtools with ldd and readelf yields the following:
$ ldd -r samtools
libnsl.so.1 => /usr/lib/libnsl.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libm.so.2 => /usr/lib/libm.so.2
libcurses.so.1 => /usr/lib/libcurses.so.1
libz.so => /usr/lib/libz.so
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libmd.so.1 => /usr/lib/libmd.so.1
libscf.so.1 => /usr/lib/libscf.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
libgen.so.1 => /usr/lib/libgen.so.1
symbol not found: gzopen64 (samtools)
$ ldd -s samtools
...(snip)...
find object=libz.so; required by samtools
search path=/usr/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib (LD_LIBRARY_PATH)
trying path=/usr/lib/libz.so
libz.so => /usr/lib/libz.so
...(snip)...
$ readelf -d samtools | grep RPATH
0x0000000f (RPATH) Library rpath: [/usr/local/apps/zlib-1.2.5/lib:/usr/local/apps/gcc-4.5.1/lib]
So /usr/local/apps/zlib-1.2.5/lib is clearly in the binary's RPATH, which I understand is supposed to be searched at runtime for shared libraries. However, ldd -s shows that this directory is never searched. Adding this path to LD_LIBRARY_PATH and re-running the ldd commands has the expected effect: the directory is searched and the correct version of libz is found.
So how can I force samtools to search in /usr/local/apps/zlib-1.2.5/lib at runtime without using LD_LIBRARY_PATH?
Edit: The documentation here would seem to indicate that the -R option is the correct thing to do. But it doesn't work.
I'm by no means a Solaris expert, but this line:
find object=libz.so; required by samtools
search path=/usr/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib (LD_LIBRARY_PATH)
seems to indicate to me that LD_LIBRARY_PATH is already set, and the /usr/lib path in it is taking precedence over any runtime linker paths. Can you unset LD_LIBRARY_PATH if it is in fact present and see if that resolves it?