Hide Forgot
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 U __ctype_b_loc@@GLIBC_2.3 U __ctype_tolower_loc@@GLIBC_2.3 U __ctype_toupper_loc@@GLIBC_2.3 U pthread_cond_broadcast@@GLIBC_2.3.2 U pthread_cond_destroy@@GLIBC_2.3.2 U pthread_cond_init@@GLIBC_2.3.2 U pthread_cond_signal@@GLIBC_2.3.2 U pthread_cond_timedwait@@GLIBC_2.3.2 U pthread_cond_wait@@GLIBC_2.3.2 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): glibc-2.3.2-4.80 How reproducible: Always 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 update installed 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. Additional info:
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 around.
Yes, but it seems irresponsible to have introduced this incompatibility in an errata update.
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 software. So, to summarize, I believe one of the two following options would be an appropriate resolution: - 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).