From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
When our product is compiled on a RedHat 8.0 system which has the glibc update,
the pthread symbols are versioned to GLIBC_2.3.2. This means that any customer
who has a RedHat 8.0 system who hasn't upgraded their glibc will not be able to
run our product.
In fact, this will be true for any binaries using the pthread_cond_*() functions
which are compiled against the new glibc, I believe. This incompatibility is a
significant headache and shouldn't have been introduced as part of a security
update, as it basically leaves us two choices:
- don't update our development systems, as the binaries built against the old
glibc will run against the new glibc
- require customers to update their glibc
Neither option is overly appealing.
Here's the list of the glibc 2.3+ symbols in the binary. In particular, the
pthread symbols (which are versioned for glibc 2.3.2) are causing the problem:
$> nm omnipbd_linux | grep GLIBC_2.3
Some sort of fix so that (at least in glibc 2.3.2 for RedHat 8.0) the older
pthread_cond_*() symbols are used instead of the new ones is really needed, as
breaking compatibility in a stable release is not a good thing.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. compile a program which uses the pthread condition functions (such as
pthread_cond_signal) on a RedHat 8.0 system which has the glibc-2.3.2-4.80
security update installed
2. try to run the program on a RedHat 8.0 system which doesn't have the glibc
Actual Results: ./omnipbd_linux: /lib/i686/libpthread.so.0: version
`GLIBC_2.3.2' not found (required by ./omnipbd_linux)
Expected Results: The program should run.
NB: I am not a redhat nor glibc developer
You can compile your app using the LSB development environment. This will lock
the binary to a set of GLIBC symbol versions that are standardised across
distributions, ie the same binary should (in theory) work not just on redhat
glibcs, but also suse/mandrake.
This is great, but please remember that new symbol versions aren't introduced
for giggles, is asking your customers to update really that bad? Otherwise, they
will be running with an insecure box.
glibc is only backward compatible, not forward compatible (no library guarantees
that). You can run old code on new systems but not necessarily the other way
Yes, but it seems irresponsible to have introduced this incompatibility in an
Brian makes my point exactly. I understand the question of forward compatibility
of glibc and don't have an issue with that. My issue is with RedHat releasing a
security errata which broke compatibility in either direction.
A security update should be very carefully checked to make sure that it doesn't
create any new problems (whether new bugs or breaking compatibility) unless the
change is absolutely required to fix the security bug.
Given that the newer glibc introduces compatibility issues, what I believe to be
the proper solution would be to patch the version of glibc installed by default
on RedHat 8.0 with the fix and re-release that version.
I wouldn't have an issue with the change if it were across RedHat versions -
i.e., RedHat 8.0 has the older glibc, RedHat 8.1 (or whatever) has the newer
one. The problem here is that we now in effect have two versions of RedHat 8.0:
glibc 2.2.93 RedHat 8.0 and glibc 2.3.2 RedHat 8.0. This creates additional
maintenance headaches, and in fact forces software vendors to do their builds on
an unpatched (and therefore insecure) RedHat 8.0 box to ensure that any customer
running RedHat 8.0 can run the software.
And yes, I agree that everybody should have installed the glibc update to
resolve the security issue. However, that's a red herring; the point is that we
should not have to require our customers to change their systems to run our
So, to summarize, I believe one of the two following options would be an
- release a new update for 8.0 systems using the old glibc, so that the
compatibility issue goes away (may not be technically feasible now that the
2.3.2 update has been out for a while)
- provide a way so that software built on a 2.3.2 system can only link against
symbols present in the 2.2.93 system
Pinging to see if there is going to be any consideration of a way to build
portable software as described in my previous response last week (which would be
good enough for our purposes).