MySQL Bugs: #1043: MySQL-shared not installable on RH9.0 due to failed dependencies

Bug #1043	MySQL-shared not installable on RH9.0 due to failed dependencies
Submitted:	13 Aug 2003 16:33	Modified:	27 Sep 2008 9:01
Reporter:	Kris Couck	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Packaging	Severity:	S2 (Serious)
Version:	4.1	OS:	Linux (Redhat Linux 9)
Assigned to:	Lenz Grimmer	CPU Architecture:	Any

Description:
When installing the MySQL-4.1.0 binary rpm's, there is a failed dependency requiring openssl 0.9.6 to be installed

On RedHat 9.0, version 0.9.7 is installed standard, and this failed dep. makes it impossible to compile PHP with mysql support as well for example

How to repeat:
see above

Suggested fix:
Build for openssl 0.9.6 AND higher?

btw, my error message on PHP compile is:

/usr/bin/ld: warning: libssl.so.0.9.6, needed by /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libmysqlclient.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libcrypto.so.0.9.6, needed by /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libmysqlclient.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libmysqlclient.so: undefined reference to `OpenSSL_add_all_algorithms'
collect2: ld returned 1 exit status

that was after I installed the MySQL-shared rpm with --nodeps btw...
mysql runs fine for the rest... had the missing libraries bug since 4.0 I think, but since it was installed on a RH7.3 system then with openssl 0.9.6 upgraded to 0.9.7, it still had the files, which are missing totally now...

btw, this might be the wrong category, didn't really know where to place it else

did some more google research, and found this:
http://rhn.redhat.com/errata/RHSA-2003-101.html

installing the openssl096/openssl096b pacakges solved my compiling problem, the dependency issues (rpm) are still not solved though...

Yes, this is a known issue. Unfortunately it's not possible to make this library
dependency "softer" - it depends on the libraries used on the build host. You can either try to install the RPMs using the "--nodeps" option, which will ignore the
dependency. Another alternative is to simply recompile the source RPM on the target system - this will make sure that the library dependencies match the ones
installed on your system. As it's not possible to link dynamically against OpenSSL, there is currently not much we can do about this, apart from building
binaries for every possible combination of shared libraries that are installed on
the various Linux distributions (which will probably create major confusion).

I am going to set this report to "deferred", until we have found a solution for
this annoying problem. Sorry for the inconvenience.

This problem occurs on SuSE version 9.0 also. 
 
I was able to successfully install MySQL-shared on the machine using --nodeps, 
and the server and command-line client work correctly. But I can't build PHP 
against the RPM installation of MySQL 4.1.1, because the RPM MySQL looks for 
OpenSSL 0.9.6, but SuSE 9 comes with OpenSSL 0.9.7. The OpenSSL libs all have 
symlinks to more generic versions (e.g., libssl.so --> libssl.so.0.9.6, and so 
on), but this doesn't seem to help. Is it not possible to tell MySQL to accept 
any available libssl? 
 
If I build MySQL from source, everything is fine. But there is a bug with 
readline/libedit support in the source-built MySQL that causes a segfault, so 
I'm using the RPM version on advice from MySQL developers. It's a catch-22.

I fat-fingered a version number in the comment just posted. 
 
The string "libssl.so --> libssl.so.0.9.6" should read 
"libssl.so --> libssl.so.0.9.7". 
 
Sorry for the error.

Though I accept that you don't want to have to provide binaries for all linux flavours, it seems 
crazy to actively prevent the installation of MySQL in this way. I did a little research - I can't find 
any major Linux distro that ships with OpenSSL 0.9.6. That means that the vast majority of Linux 
users are locked out, and the situation will only get worse as people upgrade and new 
installations appear. If MySQL was linked against 0.9.7, it would mean that it works in the vast 
majority of cases anyway, and for anyone who is still running 0.9.6, all that's needed is a simple 
update of OpenSSL. This requirement may be hard on those running locked-down systems, but 
then this is a development version - if updating OpenSSL is a problem, then installing a pre-
release version of ANYTHING won't be allowed. I really don't see any good argument for keeping 
it dumbed-down to 0.9.6.

You are right - having a shared lib dependency on an obsolete version of OpenSSL does not
service anybody. As the 4.1 Linux RPMs are the only ones that we actually compile with OpenSSL
at all, I will disable OpenSSL in these for now as well. As soon as this build system has been upgraded
to a more recent version of OpenSSL, we can decided what to do with OpenSSL in general.

Bug #4831 was marked as a duplicate of this bug.

Update: I finally managed to install OpenSSL 0.9.7d on this Linux build host now (the initial problem was 
that upgrading OpenSSL was not easily doable without breaking shared library dependencies of other 
binaries installed).

I think part of the solution to this found in the openssl packages:

foxtrot(~)$ rpm -q -provides openssl096
libcrypto.so.1  
libssl.so.1  
openssl096 = 0.9.6-26
foxtrot(~)$ rpm -q -provides openssl096b
libcrypto.so.2  
libssl.so.2  
openssl096b = 0.9.6b-18
foxtrot(~)$ rpm -q -provides openssl
config(openssl) = 0.9.7a-33.10
libcrypto.so.4  
libssl.so.4  
openssl = 0.9.7a-33.10

Link against and require the libssl.so.[124] 

Don't link against libssl.so.0.9.x or require the openssl = 0.9.7a-33.10, etc.  They are too specific.

You can read bug #4831 to more info on what works.

In the mean time, a workaround for not being able to build PHP or other packages linked agains libmysql, manually create a symlink of the name required by examining ldd on libmysql.

Unfortunately this is not easily doable, as RPM builds up the shared library dependency list by
running "ldd" against the files included in the package. As the dynamic linker uses libssl.so.0.9.x,
it will not help to override these requirements by switching off the automatic dependency generation
and manually requiring a different library version. Well, it may silence the dependency warning from
RPM during the installation, but ldd will still complain about a missing shared library.

I apologise if I'm in over my head here, but I think you're mistaken in that respect.  Here's an example of what I'm talking about:

foxtrot(~)$ ldd /usr/lib/libmysqlclient.so.14.0.0
        libz.so.1 => /usr/lib/libz.so.1 (0x0050c000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x00688000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00fa4000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00ab5000)
        libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x00ce1000)
[snip]

Let's look at the linkage against libm, clearly ldd believes it is linked against libm.so.6, and shows where it finds it: /lib/tls/libm.so.6

However, examining the file:

foxtrot(~)$ ls -l /lib/tls/libm.so.6
lrwxrwxrwx  1 root root 13 Jan 24  2004 /lib/tls/libm.so.6 -> libm-2.3.2.so*

Shows that libm.so.6 is actually a symlink to libm-2.3.2.so.

And, here we see:

foxtrot(~)$ rpm -qf /usr/lib/libmysqlclient.so.14.0.0
MySQL-shared-compat-4.1.3-0
foxtrot(~)$ rpm -q --requires MySQL-shared-compat
ld-linux.so.2
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.2)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libcrypt.so.1
libcrypto.so.0.9.6
libdl.so.2
libm.so.6
[snip]

that the dependency on libm is to the symbolic link and not to the actual library.

For what it's worth:

foxtrot(~)$ rpm -qf /lib/tls/libm.so.6 /lib/tls/libm-2.3.2.so
glibc-2.3.2-101.4
glibc-2.3.2-101.4

both libm and its link are part of glibc.  Similarly:

foxtrot(~)$ rpm -q --whatprovides libssl.so.4
openssl-0.9.7a-33.10
foxtrot(~)$ rpm -q --whatprovides libssl.so.2
openssl096b-0.9.6b-18

libssl.so.4 and libssl.so.2 are listed in the capabilities of their respective rpms, so I don't know why the build scripts would pick up libm.so.6 but have to be linked directly to a specific version of libssl or libcrypto.

I hope I'm not missing something entirely obvious or that this example is invalid for some reason.  Please correct me if I am.  

Thanks

Hi Eric, thanks for your comments and the detailed explanation. I guess you are missing something
here :)

If you look at the "-q --requires" list, you will see that it requires "libcrypto.so.0.9.6", as this is what
"ldd /usr/lib/libmysqlclient.so.14.0.0" returns. So in the case of libcrypto it actually uses the
"long" name instead of the short one to build up the requirement list. I am not sure why this is
different for the libcrypto case - but this specific dependency can only be resolved by installing
exactly this version of the library.

Anyway, I have now published MySQL-4.1.3-1 RPMs for Linux/x86 which should not have that
dependency on libssl anymore.

Interestingly, since I figured it was a problem with the linker and not the rpm scripts, I pulled the src.rpm and rebuilt it on my machine thinking I would submit a patch to the Makefiles to get the linkage right.

I had to change the spec file to use openssl, but when I did, this is what I got:

foxtrot(~)$ ldd /usr/src/redhat/BUILD/mysql-4.1.3-beta/libmysql/.libs/libmysqlclient.so.14.0.0
        libz.so.1 => /usr/lib/libz.so.1 (0x002e0000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x00672000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00e90000)
        libm.so.6 => /lib/tls/libm.so.6 (0x003a0000)
        libssl.so.4 => /lib/libssl.so.4 (0x00111000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x00531000)
[snip]

It correctly (IMO) links to the lib{crypto|ssl}.so.4 links instead of the actual lib*.so.0.9.7a's that are installed on my machine.

Now, knowing that the .so.4 links are created by the postinstall script for the openssl package and not included in the actual rpm as files, I'm wondering if the standard openssl install target actually creates these links or if they are a RedHat/Fedora-ism.  And, if so, are the openssl libs on your build machines built from scratch or installed from rpm?

ld should seek out the highest version library for any given -lblah directive, which would be .so.4 in this case, if the links exist.  Is the solution as simple as to install your openssh libs from rpm?

And, just a check to be sure:

foxtrot(~)$ rpm -q --qf '%{VENDOR}\n' openssl
Red Hat, Inc.

I *am* using the vendor supplied openssl packages and not some from another source.

Thanks

Lenz, thanks for the new RPMs.  

I was confused by the --without-openssl in the spec file until I read your reply above.  I don't use ssl, so that works fine for me.  If openssl becomes a requirement down the line, it may be useful to observe my results in the above comment. 

But, at this point it's an academic exercise, so I'm going to drop it and consider the bug closed.

It's been a year since this was touched, and MySQL 4.1 now ships in RHEL 4 with this problem.  Being included in RHEL 4 gets you into a lot of enterprise environments (including mine) where SSL may soon be a requirement.  Any progress on this?

David, can you elaborate on "ships with this problem"? What problem are you referring to exactly?
It would probably be better to open a new bug report about this, with a clear description of what the problem is. Thanks!

problem = no SSL support.  It's purposely disabled in the spec file, and the comments in the changelog section of the spec file indicate it was disabled by MySQL folks before Red Hat started playing with it (which is how I found this bug, the bug number is referenced in the changelog)

I believe this is not relevant any more due to 2 things:
- the platform is considered old nowadays
- starting from 5.0 mysql ships with built-in yassl.