> ---------------------------------------------------------------------- > OpenSSL Shared Libraries have been installed in: > [directory name] > > If this directory is not in a standard system path for dynamic/shared > libraries, then you will have problems linking and executing > applications that use OpenSSL libraries UNLESS:
There is another option, "The Right Thing":-) To start with the problem is formulated incorrectly in my opinion. To make 'ldd libssl.so' work is not actually *the* goal, 'ldd openssl' or 'ldd target-app' is. And the first priority answer to the problem should be *embedded* run-time library path. Well, it can be embedded even into .so object, but it's not necessary a good thing. Because you might want to include a copy into some bigger package and install it in alternative location. Embedded run-time library path belongs in application, not .so, and that's what you want to control. How does one control the run-time library path in general? Yes, crle is a way, but it first appears in Solaris 8, it's pain in network environment (you have to configure it on every damn machine) and is not plain-user friendly. Yes, LD_LIBRARY_PATH[_64] environment variable is another way, but you don't want to rely on it as users are bound to fail to [re]set it. Finally (the option I refer to as "embedded run-time path"), it's possible to set LD_RUN_PATH at link time or pass -R flag to the linker(*). Currently OpenSSL does embed run-time path into .so on some OSes (Tru64?), but I for one am not actually fond of it. As already mentioned [even last year] I believe that it should be embedded into application where it belongs (.so never run). Another argument against embedding it onto .so is presence of multiple ABI and not having real control over which ABI was actually chosen. It's those who deploy the toolkit [are expected to] have the grip over the run-time library path (they might even choose to embed multiple path), not us. That's what I basically ment last year that we should stand for code and documentation, but not for the run-time path itself. Well, we have to care about openssl application itself, but again, not by embedding the run-time path into .so, but into the application. Bottom line. +1 for proposed documentation with explicit mention and prioritizing (i.e. #2 after static linking:-) of embedded run-time path and lowering LD_LIBRARY_PATH priority. As for pkgconfig. I know nothing about it, but assume that openssl.pc has everything to do with it. I think it's a good idea to put -R/-rpath into it. (*) Most OSes support equivalent option. Most notably -rpath (Linux, Tru64, IRIX). And when it comes to Solaris and Linux there is an easter egg here. Starting with 2.6 Solaris run-time linker implements support for $ORIGIN. E.g. if you pass -R \$ORIGIN/../lib to the linker, the application will be looking for .so objects in ../lib relative to the application binary. This $ORIGIN thing is very useful. It's so useful, that it's tempting to wrap openssl binary into a script which would emulate $ORIGIN on platforms that lack $ORIGIN. Yes, approximately the way autoconf does in build tree. Should I look into it? A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
