MySQL Bugs: #19288: Package "shared compat" might not conain newly build 5.0/5.1 shared libs

Bug #19288	Package "shared compat" might not conain newly build 5.0/5.1 shared libs
Submitted:	23 Apr 2006 17:19	Modified:	9 May 2006 18:50
Reporter:	Kent Boortz	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Packaging	Severity:	S3 (Non-critical)
Version:	5.0.18 5.1.7	OS:
Assigned to:	Kent Boortz	CPU Architecture:	Any

Description:
There are now "shared compat" packages for all RPM
platforms, including specific packages for Red Hat and
SuSE. The idea with this package is to contain all shared
library versions, currently "soname" of 10, 12, 14, 15.

The current build will create this package from the
"shared" packages released for 3.x, 4.0, 4.1, 5.0 and
5.1. This is not correct, 5.0 and 5.1 has the same
"soname", and in effect depending on which one was
unpacked last, the package might contain the shared
library from the latest 5.0 release or the 5.1 release.

When creating a 5.0 release, the corresponding shared
compat package should contain the newly built 5.0
shared libraries, and when creating a 5.1 release the
corresponding shared compat package should contain
the newly built 5.1 shared libraries.

How to repeat:
Review the spec file used to create the RPM.

Suggested fix:
Improve the build script to check the "soname"
in the RPMs it try use for creating the shared compat
package. Also favor the shared libraries in the newly
built release.

IMHO, a "shared-compat" for 5.0 should never contain a 5.1 library, 
as I fear a new client (or else it would not need the 5.1 library) is quite likely 
to use features which only a new server can support.

I always assumed the "shared-compat" packages to (only!) support old clients 
(especially ones which the user did not build himself) in accessing a new server,
so that the user could upgrade the server and still run the existing clients.

The fact that the shared-compat contains 5.1 libraries is causing other application compilation problems. See bug #18091.

Actually I must take back the previous comment.
Although this is true that the shared-compat wrongly contains the 5.1.x shared libs, it is not the only reason for 3rd party apps compilation failure.

If you install shared-compat, you will get these libraries:

libmysqlclient.so.14.0.0  -- some older compat version (OK)
libmysqlclient.so.15.0.0  -- version 5.1.7 beta (not OK)

Since libmysqlclient.so is linked to libmysqlclient.so.15.0.0, the 5.1.7 beta libs are used during compilation of PHP, etc. which fails with the known error message "relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC"

If you install shared libs only, you will get the library:

libmysqlclient.so --> libmysqlclient.so.15.0.0  -- version 5.0.20a (seems OK)

The compilation STILL fails, with the same error message, so everything in the bugs #13159 and #18091 is true even without the 5.1.x beta libs.

Release 5.0.21 seems to fix the issue of included 5.1 library.
At least for the x86_64 Linux distribution.
The libraries in shared_compat are correct now.

The build script that creates the "shared compat" packages
now favor packages just built. It also no longer include
shared libraries for later releases.

The corrected packages are in MySQL 4.1.19 and 5.0.21.

Noted in 4.1.19, 5.0.21, 5.1.10 changelogs.