Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: lddproblems
OK, I've hacked a little. Please try the following patch on a 0.9.7 snapshot, and put the attached openssl-shared.txt in doc/: Index: Makefile.org === RCS file: /e/openssl/cvs/openssl/Makefile.org,v retrieving revision 1.154.2.49 diff -u -u -r1.154.2.49 Makefile.org --- Makefile.org9 Jan 2003 16:15:06 - 1.154.2.49 +++ Makefile.org10 Jan 2003 12:03:15 - @@ -763,6 +763,12 @@ cd $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \ set $(MAKE); \ $$1 -f $$here/Makefile link-shared ); \ + if [ $(INSTALLTOP) != /usr ]; then \ + echo 'OpenSSL shared libraries have been installed in:'; \ + echo ' $(INSTALLTOP)'; \ + echo ''; \ + sed -e '1,/^$/d doc/openssl-shared.txt; \ + fi; \ fi cp openssl.pc $(INSTALL_PREFIX)$(INSTALLTOP)/lib/pkgconfig The OpenSSL shared libraries are often installed in a directory like /usr/local/ssl/lib. 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: * you link with static (archive) libraries. If you are truly paranoid about security, you should use static libraries. * you define the LD_LIBRARY_PATH, LIBPATH, SHLIB_PATH (HP), DYLD_LIBRARY_PATH (MacOS X) or PATH (Cygwin and DJGPP) environment variable and add the OpenSSL shared library directory to it, and use the -L linker option. * you use the GNU libtool code during linking (http://www.gnu.org/software/libtool/libtool.html) * you use pkg-config during linking (this requires that PKG_CONFIG_PATH includes the path to the OpenSSL shared library directory) (http://www.freedesktop.org/software/pkgconfig/) * you specify the system-wide link path via a command such as crle(1) on Solaris systems. * you add the OpenSSL shared library directory to /etc/ld.so.conf and run ldconfig(8) on Linux systems. One common tool to check the dynamic dependencies of an executable or dynamic library is ldd(1) on most UNIX systems. See any operating system documentation and manpages about shared libraries for your version of UNIX. The following manpages may be helpful: ld(1), ld.so(1), ld.so.1(1) [Solaris], dld.sl(1) [HP], ldd(1), crle(1) [Solaris], pldd(1) [Solaris], ldconfig(8) [Linux].
Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: lddproblems
-- 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]
Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229:lddproblems
In message [EMAIL PROTECTED] on Fri, 10 Jan 2003 15:03:00 +0100, Andy Polyakov [EMAIL PROTECTED] said: appro There is another option, The Right Thing:-) Of course :-). Unfortunately, about -R/-rpath, I've avoided it so far for exactly the reason you mentioned: it doesn't quite support moving libraries to a dofferent place and still have it work. And also, I have understood that libssl.so does need a -R/-rpath to be able to find libcrypto.so, on which it depends. And you're quite correct, the openssl application should be linked with it, which we don't do at all today... appro (*) Most OSes support equivalent option. Most notably -rpath (Linux, appro Tru64, IRIX). And when it comes to Solaris and Linux there is an easter appro egg here. Starting with 2.6 Solaris run-time linker implements support appro for $ORIGIN. E.g. if you pass -R \$ORIGIN/../lib to the linker, the appro application will be looking for .so objects in ../lib relative to the appro application binary. This $ORIGIN thing is very useful. It's so useful, appro that it's tempting to wrap openssl binary into a script which would appro emulate $ORIGIN on platforms that lack $ORIGIN. Yes, approximately the appro way autoconf does in build tree. Should I look into it? That's a good idea. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229:lddproblems
Unfortunately, about -R/-rpath, I've avoided it so far for exactly the reason you mentioned: it doesn't quite support moving libraries to a dofferent place and still have it work. And that is what I'm suggesting to adhere to. I.e. to avoid it (and even to remove it from tru64!) and leave this final decision to those who deploy the toolkit. And also, I have understood that libssl.so does need a -R/-rpath to be able to find libcrypto.so, on which it depends. This is not true. The fact that 'ldd libssl.so' says can't locate libcrypto.so does *not* mean that libssl.so is bound to fail to link with libcrypto.so. -L and -R options at *application* link time provide for that. -R/-rpath option at libssl.so link time can and should be omitted. -R/-rpath option at *application* link time is the one to be used. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #423]openssl-0.9.7-stable-SNAP-20021229:lddproblems
In message [EMAIL PROTECTED] on Fri, 10 Jan 2003 17:40:18 +0100, Andy Polyakov [EMAIL PROTECTED] said: appro And also, I have understood appro that libssl.so does need a -R/-rpath to be able to find libcrypto.so, appro on which it depends. appro appro This is not true. The fact that 'ldd libssl.so' says can't locate appro libcrypto.so does *not* mean that libssl.so is bound to fail to link appro with libcrypto.so. -L and -R options at *application* link time provide appro for that. -R/-rpath option at libssl.so link time can and should be appro omitted. -R/-rpath option at *application* link time is the one to be appro used. Ah, so recursive loads inherit the -R/-rpath values? It's good to know I misunderstood this. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: lddproblems
Hi, Here's the text I came up with: -- 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: * you link with static (archive) libraries. If you are truly paranoid about security, you should use static libraries. * you define the LD_LIBRARY_PATH or SHLIB_PATH (HP) environment variable and add [directory name] to it, and use the -L linker option. * you use the GNU libtool code during linking (http://www.gnu.org/software/libtool/libtool.html) * you specify the the system-wide link path via a command such as crle(1) on Solaris systems. One common tool to check the dynamic dependencies of an executable or dynamic library is ldd(1) on most UNIX systems. See any operating system documentation and manpages about shared libraries for your version of UNIX. The following manpages may be helpful: ld(1), ld.so(1), ld.so.1(1) [Solaris], dld.sl(1) [HP], ldd(1), crle(1) [Solaris], pldd(1) [Solaris]. -- I looked at the Makefile to see where it might go. make install invokes make link-shared near the end of the install process. The text could be printed at that point. A really good way to do this would be to have the text above broken into two pieces, one generic for all UNIX, and one specific to the OS. The specific piece could be printed out perhaps when the Makefile do_$(SHLIB_TARGET) target is invoked. That way the quirks of dynamic loading on Solaris, HP, Linux, could be explained and the correct manpages referenced. --- Jeff On Wed, 1 Jan 2003, Richard Levitte - VMS Whacker via RT wrote: Date: Wed, 1 Jan 2003 14:58:09 +0100 (MET) From: Richard Levitte - VMS Whacker via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: ldd problems In message [EMAIL PROTECTED] on Wed, 1 Jan 2003 13:36:23 +0100 (MET), Jeff A. Earickson via RT [EMAIL PROTECTED] said: rt man crle on a Sun box. It is: Not on the machine I currently have access to :-): $ man crle No manual entry for crle. rt crle - configure runtime linking environment rt rt which determines the search path for dynamic libs. I had forgotten rt that I had added /opt/openssl/lib to this path. When I was testing rt 0.9.7 in various forms, I installed it in /opt/openssl-0.9.7, but rt forgot to add the path via crle. So I couldn't get dynamic loading rt to work and was going nuts... Can you recommend some piece of text that should be output? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #423] openssl-0.9.7-stable-SNAP-20021229: lddproblems
In message [EMAIL PROTECTED] on Wed, 1 Jan 2003 13:36:23 +0100 (MET), Jeff A. Earickson via RT [EMAIL PROTECTED] said: rt man crle on a Sun box. It is: Not on the machine I currently have access to :-): $ man crle No manual entry for crle. rt crle - configure runtime linking environment rt rt which determines the search path for dynamic libs. I had forgotten rt that I had added /opt/openssl/lib to this path. When I was testing rt 0.9.7 in various forms, I installed it in /opt/openssl-0.9.7, but rt forgot to add the path via crle. So I couldn't get dynamic loading rt to work and was going nuts... Can you recommend some piece of text that should be output? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]