Andreas M. Kirchwitz via RT wrote:
Hello!
Richard Levitte - VMS Whacker via RT wrote:
> I just found an email discussion that seems to cover what's happening
> to you:
> > http://sources.redhat.com/ml/bug-glibc/2000-01/msg00046.html
Yeah, it seems like I'm hit by exactly the same issue. ;-)
Ran in to this yesterday, where 0.9.7d was in the -rpath directory but was trying to build OpenSSH-3.9 that was testing if the OpenSSL headers matched the libs. The test had set LD_LIBRARY_PATH as expected to point to the new OpenSSL-0.9.7e. It worked on Solaris and newer HP_UX but failed on Linux and HP-UX 11.0.
The man pages for ld on Linux say -rpath is used first. This is unfortunate as it means you can't build a number of different packages to be installed as a group, or even to test the newly built library.
One of the problems is that different sub releases of OpenSSL use the same library names 0.9.7 where as a new release which adds functionality such as the AES-265-... should increment the library version.
As it seems, Linux behaves this way for years. I'm really surprised that I've never noticed the difference before. But usually, I prefer to use -R/-rpath so that I don't need to set LD_LIBRARY_PATH at all. Maybe that's why it didn't matter for me so far.
> The question I have to you is if you have LD_RUN_PATH set in some way, > or if you did something that sets -rpath when linking the libraries > and applications. As I understand it, directories given with -rpath > can't (and shouldn't, which makes sense) be overriden with > LD_LIBRARY_PATH.
Sorry that I didn't mention it earlier (that's typical for users, they always "forget" such important details ... shame on me ;-), yes, I did modify the variable "EX_LIBS" in the global "Makefile" (on Linux I add "-L/usr/local/ssl/lib -Wl,--rpath=/usr/local/ssl/lib", "-R/usr/local/ssl/lib" on Solaris), otherwise libssl.so wouldn't find libcrypto.so. This sounds like a good reason at first sight, but turns out to be silly at second sight, because if somebody wants to use libssl.so he has to include /usr/local/ssl/lib anyway (thus, automatically finding libcrypto.so as well). I cannot exactly remember what it was, but one day this became an issue for some reason, otherwise it wouldn't have come to my attention (I usually don't do "ldd" on libraries as long as they work fine with the program they are linked to) and I wouldn't have put any effort in modifying the Makefile manually. But as said, I don't remember what issue made me do this. ("It's the voices! The voices in my head make me do such things!" ;-)
I also could add /usr/local/ssl/lib to the system-wide search path for libraries, but I don't want the system binaries to use my OpenSSL, I only want to use it for my self-compiled software in /usr/local.
>> Maybe the use of LD_PRELOAD is worth a thought to be put into the
>> OpenSSL test procedures (make test).
> > I'm thinking you're right.
I have to admit, that my configuration seems to be some kind of weird at least. On the other hand, setting -R/-rpath/LD_RUN_PATH to a perfectly legal path like "/usr/local/ssl/lib" shouldn't break "make test".
However, thanks a lot for you answer. I'm happy, that nothing is really "wrong", but that this different behaviour is by definition. ;-)
Greetings, Andreas
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
