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).
magixmanAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Duncan RoeSoftware DeveloperCommented:
You're not going to like this: compile and link on the old box if you want compatibility. Glibc is just too fundamental a part of the system to offer it backwards.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
magixmanAuthor Commented:
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.
Duncan RoeSoftware DeveloperCommented:
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?
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

magixmanAuthor Commented:
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)
 
Duncan RoeSoftware DeveloperCommented:
"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.
ahoffmannCommented:
You have to link against a glibc which is available on the other system, this also requires that all other libraries you're using can use that old glibc. IIRC you also have to use a proper compiler for that, in particular the compiler relies on glibc too (as duncan_roe already pointed out). And finally don't forget to use the proper include files for that old glibc.
To do all that, you have to tweak the compiler and linker with a couple of options and ensure that it only finds those includes and libs.
I'd use a chrooted sandbox for that (even it can be done directly).
magixmanAuthor Commented:
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.
ahoffmannCommented:
>  There is no 'Easy Button' such as just including some old headers.
use the old tools, cause they are not forward-compatible, probably ... :-)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.