Link to home
Start Free TrialLog in
Avatar of magixman
magixman

asked on

Compile and Link for Compatibility With Older Versions of GLIBC

I thought this would be easy.  I retired my old Linux 7.3 system and we now do our development on a brand new CentOS system (REL 3.4).  Now, however, some of the things we compile generate an error when run on older Linux systems saying that GLIB_2_3 is required.   I have spend a considerable amount of time researching this and have found no satisfactory solution and yet there must be an obvious one as all developers don't keep old Linux boxes around just to do compile and links or do they?

I tried using the compat-gcc-32 packages but the particular package I am compiling (a DBD-mysql-3.002 perl module in one case) generates compile errors I include these headers.

Would appreciate any input on best practices for compiling and linkingin a way that will be back compatible to at least Linux 7.x (say GLIBC 2.2.4).
ASKER CERTIFIED SOLUTION
Avatar of Duncan Roe
Duncan Roe
Flag of Australia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of magixman
magixman

ASKER

This is an answer I have heard and it may be the right one but I don't accept it.  Sure I can set up a VMWare environment with an old Linux version but there just has to be a better way.  I cannot believe that all developers kick the dust off their ancient versions of Linux every time they compile stuff.  God help them if these old insecure kernels are out on the net.
It's not Linux versions, it's library versions that make a difference. Changing those is not to be undertaken lightly. What exactly is the error you get BTW?
I realize that I am trivializing things by equating GLIBC versions with Linux versions.  As you point out, changing GLIBC versions is not to be taken lightly and so one generally goes with the one that comes with the particular version of Linux you install.  What I don't understand is why everyone who creates binary products does not run into this problem and why there is not an obvious procedure for compiling/linking with older versions of GLIBC.

The error that I run into is ./mysql.so: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by ./mysql.so)
 
"everyone who creates binary products" generally tell you what revs of what distros they're tested against. And I agree you don't want to revert glibc on your new system.
When I worked for a coy that produced binary packages for distribution, they had a build environment on old revs just like you say. Sure, develop on your new system, but recompile all code from source on your old one - it's common practice.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
OK I stand corrected.  Developers such as us who go against the grain and opt for binary distros of our software might as well get used to kicking the dust off of our old environments whether they be full metal, virtual or chroot.  There is no 'Easy Button' such as just including some old headers.
>  There is no 'Easy Button' such as just including some old headers.
use the old tools, cause they are not forward-compatible, probably ... :-)