Christian- Thanks very much for your response. That information is definitely
helpful. I'll take some time to process this and work towards your solution.
> Date: Thu, 21 Jun 2012 07:25:24 +0200
> From: christ...@hohnstaedt.de
> To: openssl-users@openssl.org
> Subject: Re: OpenSSL linking question; handling 1.0.0 vs 0.9.8
>
> Hi Jason,
>
> some general things about linking:
>
> - The symbolic link(s) libcrypto.so pointing to libcrypto.so.0.9.8
> are only needed during BUILD time. On a host where no compiling
> happens the symbolic links are not required.
>
> - While linking the application, the linker opens the library
> libcrypto.so.0.9.8 by accessing the symbolic link
> libcrypto.so and reads its SONAME:
> $ objdump -x /usr/lib/libcrypto.so | grep SONAME
> This name (which has no path) is added to your application:
> $ objdump -x /usr/bin/openssl | grep NEEDED
>
> - When executing the application, the /lib/ld-linux.so link helper
> searches in the well known places $LD_LIBRARY_PATH:/lib:/usr/lib
> for the libraries and opens them recursively.
> To show which library file is actually used during execution, call:
> $ ldd /usr/bin/openssl
>
>
> To solve your problem, I suggest to compile but not install "openssl-1.0.1c"
> on the second machine and only copy the resulting libraries "libssl.so.1.0.0"
> and "libcrypto.so.1.0.0" to /usr/lib without touching their names, the
> symlinks
> nor the include/openssl.
>
> This way, any application compiled on that host will link to 0.9.8,
> while applications compiled against 1.0.x will also run smoothly.
>
> HTH
>
> Christian
>
>
> On Wed, Jun 20, 2012 at 05:56:07PM +0000, Jason Schultz wrote:
> >
> >
> >
> >
> > I'm building and running an application that uses OpenSSL on SUSE Linux. I
> > don't know a lot about linking in general, just very basic stuff, so my
> > question might be better posed to a Linux forum, but it might be specific
> > to OpenSSL. Let me describe the scenario.
> >
> > I have built installed OpenSSL 1.0.1c on one machine; built as a shared
> > library(with "shared" option on ./config). I build my application and run
> > it on this machine, dynamically linking OpenSSL. After some trial and
> > error(to get the application to use the new OpenSSL instead of the the
> > previous install of 0.9.8r), everything works fine, my application is using
> > OpenSSL 1.0.1c. Now, let's say I want to run my application on another SUSE
> > Linux machine. However, this machine has 0.9.8r(or any 0.9.8 level)
> > installed. When I try to run the application, I get an error saying it
> > can't find OpenSSL 1.0.0. I know that there are symbolic links set up when
> > installing OpenSSL, so libssl.so will be linked to libssl.so.1.0.0 after
> > installing OpenSSL 1.0.1c. (Similar for libcrypto.so) But in the old
> > branch, the link is set up with libssl.so pointing to libssl.so.0.9.8.
> > When I build my application, it seems to know that it's looking for
> > libssl.so.1.0.0, instead of just the generic libssl.so. I'm basing this on
> > doing a readelf -d on my the .so file my make produces, and seeing the
> > following line: (NEEDED) Shared library: [libssl.so.1.0.0]
> > On the machine I moved my application to(with the older OpenSSL), the link
> > where OpenSSL exists shows libssl.so linked to libssl.so.0.9.8, obviously.
> > I started messing around with trying to build 1.0.1c to "look like" 0.9.8
> > by changing the SHLIB_VERSION_NUMBER in Makefile.org and
> > /crypto/opensslv.h, but that started getting confusing and is probably
> > beyond the scope of my knowledge at this point. I've done it before with,
> > for example, going from 0.9.8i to 0.9.8r and didn't have any problems. I
> > suppose because the symbolic links look the same. Has anyone had to do this
> > before? A point in the right direction would be appreciated. Is this even
> > possible to go between branches like that?
> >
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
