MySQL Bugs: #32165: 6.0.3 binary depends on the not-installed-by-defaul -compat version of libstdc++

Bug #32165	6.0.3 binary depends on the not-installed-by-defaul -compat version of libstdc++
Submitted:	7 Nov 2007 16:15	Modified:	29 Sep 2009 11:00
Reporter:	Philip Stoev	Email Updates:
Status:	Unsupported	Impact on me:	None
Category:	MySQL Server: Packaging	Severity:	S3 (Non-critical)
Version:	6.0.3	OS:	Linux (Fedora Core 7)
Assigned to:	Joerg Bruehe	CPU Architecture:	Any
Tags:	qc

Description:
Hello, the 6.0.3 binary from the production server will not run without libstdc++-compat RPM which is not installed by default on Fedora Core 7

How to repeat:
1. Install 6.0.3 linux binary on a vanilla Fedora Core 7 system.
2. Attempt to run mysql-test-run, it will fail 
3. Start the Package manager, search for libstdc++ and install the -compat RPMs
4. Run the server again, it will work.

Suggested fix:
A. Document the new libstdc++ dependency introduced by Falcon, in particular that the libstdc++-compat RPMs will be required on newer systems.

B. Consider building against a newer version of libstdc++ so that the dependency is satisfied by default on a standard install of Fedora Core.

Thank you for the report.

Please check if you use icc binaries and this is duplicate of bug #28202

No, this bug applies to the normal gcc-compiled binaries.

Release builds including Falcon
(which requires using "g++" as opposed to "gcc" for C++ files)
have been postponed, so this doesn't seem urgent.

I cannot understand why version 5.4 is mentioned:
We use "gcc" there for the C++ files, like we do in 5.0 and 5.1.
There was an exception in 5.4.1 whose reason i didn't check, but after that we reverted to the 5.0/5.1 method.
So I delete 5.4 from the "version" field, and set the target version to 6.0.

The build team is aware of the dependency problems introduced by C++, which are much more complicated than those with the C library ("glibc 2.3" is compatible across all Linux distributions).
For C++, we are considering two different approaches:

1) Include the C++ library version number in the package name.
On the download pages, there would then be a list which distribution (version) uses which C++ library version,
and the command how to check the library version.
The user would then download the correct package.

2) Include the distribution (version) in the package name.
We would use the most frequent distribution (for a given C++ library version), and on the download page there would be a list of other matching distributions (versions).

The decision which approach to use has not yet been made.

(Approach B of the problem report won't work if it gets us ahead of the C++ library on other platforms.)

In any case, the C++ dependencies will prevent us from having "generic" packages (like we have in 5.0 and 5.1).
This will probably require us to build on more platforms, just to link to different versions of the C++ runtime lib. These machines are not yet set up.

We plan to ensure the correct handling of all such dependencies when we use "g++", so the bug fix will be an automatic consequence of that change.

Because of all this, I set this bug to "To be fixed later".