> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf > Of Wouter Verhelst > Sent: Monday, May 29, 2017 10:40 > > 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. Agreed, though in the particular case where library A depends on library B, and the two are normally kept together in the same directory (whatever that directory might be), library A could have an RPATH entry of $ORIGIN to help the loader find B in the same directory. In general, though, RPATHs are bad for software that's going to be distributed to other systems, since they bind an installation directory into the binary. As Wouter says, that violates the principle of least surprise. In the products I work on, we avoid this issue with OpenSSL in particular by building OpenSSL as dynamically-linkable code (PIC, etc, as necesary for each platform), but put the objects into static (Windows) or archive (*ix) libraries. Then we link those libraries into dynamic objects of our own, with additional code on top of the OpenSSL APIs. That prevents accidental run-time binding to some other OpenSSL build that happens to be on the system. It requires hacking the OpenSSL build process, though, which doesn't natively accommodate this "build static libraries for subsequent dynamic linking" model. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
