On 28-05-17 23:51, Jeffrey Walton wrote: > So what are the problems here that need to be addressed? I think I > know some of them: > > 1. Build OpenSSL with an RPATH if installed in non-system location > 2. Build user program with an RPATH if OpenSSL installed in non-system location > 3. Use another mechanism when Linux RATH not available (OS X, Solaris, friends) RPATHs have advantages, but they have some major issues, too. For instance, if for whatever reason you need to move files around so that things are stored in a different location, suddenly you'll need to recompile everything -- because the RPATH is a hardcoded location of the library in use. This is very confusing, and not something that an average developer will expect. There is usually no need to hardcode the location of the library in use, provided the SONAME is configured correctly. Surprise surprise, OpenSSL actually does that right: wouter@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 |grep SONAME SONAME libssl.so.1.0.2 wouter@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.1 |grep SONAME SONAME libssl.so.1.1 There is no way that ld.so will load libssl1.1 for an application that is compiled against libssl.so with an SONAME of libssl.1.0.2 -- unless, of course, you do things like muck about with RPATH and point it to the wrong version of the library. In that case, you broke it, you get to keep both pieces. > 4. External build tools like Autotools and Cmake Those are set up to assume that if a library has a particular SONAME, it will be compatible with other versions of that same library. That's usually the correct assumption. Ignoring bugs in configure.ac/Makefile.am and/or CMakeLists.txt files (those are just code too, you know), IME autotools and CMake usually just DTRT, by simply using things like pkg-config to produce the correct -I and/or -L search paths. If you insist on not using them though, that's also possible: %.o: %.c $(CC) -o $@ -c `pkg-config --cflags openssl` $^ target: foo.o bar.o baz.o $(CC) -o $@ `pkg-config --libs openssl` $^ The only reason why you would ever want to use RPATH with OpenSSL is because you need to install a particular old version of libssl (or libcrypto) that has the same SONAME as the system-default, but where you don't want to use that system-default one -- but why would you want to do that? Security updates are a good thing, usually. RPATH support is nice for corner cases, but it should not be the default, ever. -- Wouter Verhelst -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
