"libc.so.6: version `GLIBC_2.4' not found" when running library on different machine

[mventimi]

First, let me say that I'm not sure if this is more of a Perl or Linux question. If it's the latter, then I apologize in advance for posting this in the Monastery.

I am trying to run a customized version of the GD graphics library from a Perl script on my web page, which is hosted by another company. To do this, I downloaded GD, the libraries on which it depends, and the Perl GD interface module to my FC6 machine. I then made the edits I need and built and installed everything. Everything works on my machine, as verified by a test script that I wrote.

I then grabbed the entire blib directory that I built and moved it to my web server. It fails with the following (I have CGI::Carp qw(fatalsToBrowser) turned on so that it displays to the web page):

Software error:

Can't load '/home/markve65/public_html/cgi-bin/blib/arch/auto/GD/GD.so
+' for module GD: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (r
+equired by /home/markve65/public_html/cgi-bin/blib/arch/auto/GD/GD.so
+) at /usr/lib/perl5/5.8.8/i686-linux/DynaLoader.pm line 230.
at testGD.pl line 12
Compilation failed in require at testGD.pl line 12.
BEGIN failed--compilation aborted at testGD.pl line 12.

The Perl script dies at line 12, which is the "use GD;" line. If I comment this out, the script runs fine.

My first guess was that I built the library on a machine with a newer version of libc than what was on my web server machine. I checked my web server and it's running RHL9, so I grabbed a copy of RHL9, installed it on a free machine, and rebuilt as above. When I did that, however, the script died with a 500 error, and I get a "Premature end of script headers" in the error log.

The obvious answer would be to build this library on the web server machine, but I don't have access to do that. I need to build the library on a different machine and copy it over there. Can anyone give me any hints as to how I can do that? From what I've been able to dig up so far, I'm having a problem because glibc uses symbol versioning and I'm building my library on a machine with a newer glibc. The library then expects these newer versions of symbols on the machine with the older glibc. Is there any way to force the linker to use the older versions of symbols in glibc? Or am I completely off base here?

[Zaxo]

That sounds like two distinct errors, though a lib failure might produce the 500. You'd find it helpful to have shell access on the server to diagnose this. Failing that, try running your script on the spare box with RHL9. You'll get better error messages running your cgi script in the shell. See the CGI docs for how to feed it cgi params from the command line.

The strace util is very helpful for detailed diagnosis of failed system calls. Dll search path differences are a likely culprit.

[shmem]

I checked my web server and it's running RHL9, so I grabbed a copy of RHL9, installed it on a free machine, and rebuilt as above.

Since that failed, there's more to it. Make a cgi script that runs 'rpm -qa' via system and provides you the results. Level your RHL9 host matching that output, and rebuild your GD module. That might fail if your provider is paranoid^Wsane, he might install the rpm packages needed for updates on the fly during updates and remove them after, but you might succeed in that.

The obvious answer would be to build this library on the web server machine, but I don't have access to do that.

If your hoster is worth 5 cents, he will not have a build environment on the webserver itself: no gcc, make, bison, yacc, whatever.