On Fri, Nov 03, 2000 at 01:45:59PM +0100, Villy Kruse wrote:
> On Wed, 1 Nov 2000, Lutz Jaenicke wrote:
> > If you are using shared libraries, you either have to recompile your
> > application or must make sure, that the correct shared library is being
> > used. This is typically assured by including the version number into
> > the shared library name: "libssl.so.0.9.6" etc.
> >
>
> Which means that the soname as defined in the tope level Makefile
> should change from lib$$i.so.${SHLIB_MAJOR}
> to lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR}
I have just downloaded the latest snapshot; it shall contain support for
HP-UX shared libraries "out of the box" and I always wanted to try it anyway.
Here is set:
SHLIB_EXT=.sl.$(SHLIB_MAJOR).$(SHLIB_MINOR)
so this rule is already applied.
> Not sure if this fixes the problem, but the soname should in principle
> be pumped every time binary compatibility is lost.
I am not sure about the linux scheme of shared library loading.
If the library name was always hardcoded down to the detail "libssl.sl.0.9.6",
then there is no misunderstanding.
The problem arises, if the detailed name is not set but only the name
used for linking "libssl.sl" is set. In this case the latest available
shared lib is being used, which leads to the problem described.
I don't know, how this problem is best tackled with the Linux tools.
At HP-UX the internal library name is set with the "+h internal_name"
option during shared library build with "ld".
> Then you have this little problem of makin the rpm system not delete
> the old version of libssl when upgrading to the next version but keep
> both on the system
I assume that there are solutions available, since openssl for sure is not
the first package exhibiting this problem :-)
> This could be reflected in the openssh rpm package as being dependend
> on openssl version 0.9.5a, which will raise a complint when you later
> upgrade to 0.9.6 of openssl.
Yes and no. Actually, only the libssl.so.0.9.5a and libcrypto.so.0.9.5a
components are really needed. There is no reason why the developers
tools (includes, static and shared libraries) of a newer version should
not be installed while the older shared libs are still kept.
This would effectivly stop you from ever upgrading, if you have a package
of which the maintainance was stopped (from time to time you had to
adjust your source for later versions of openssl...).
Maybe one could seperate the package into "runtime" and "developers"
package? But then, the openssl binary, to which package should it belong?
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
