Running a C program compiled here causes a GLIBC l

问题:

A C program compiled here runs fine on our Ubuntu servers. But when a somebody else tries to run it on their particular Linux server they get the following errors:

./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./myprog-install)
./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.7' not found (required by ./myprog-install)

Do I need to upgrade our glibc libraries and recompile? Or are they missing something on their server?

If I run apt-cache show libc6 my Ubuntu tells me the version is:

Package: libc6
Priority: required
Section: libs
Installed-Size: 9368
Maintainer: Ubuntu Core developers <[e-mail]>
Original-Maintainer: GNU Libc Maintainers <[e-mail]>
Architecture: i386
Source: eglibc
Version: 2.11.1-0ubuntu7.10

If I look at http://packages.ubuntu.com/hardy/libc6 the current version appears to be 2.7-10ubuntu8.1.

I'm confused by the numbers. On the one hand 2.11-1-0 is a higher number than 2.7-11. On the other hand 7.10 is a lower number than 8.1.

Is it just a matter of me upgrading the C library package and recompiling do you think? Or is the other person's server missing some needed library there for compatibility?

回答1:

You have built on glibc-2.11 system. You are trying to run on a system with glibc-2.3 or older. That's not going to work.

Is it just a matter of me upgrading the C library package

No: upgrading your glibc will only make things worse.

You may want to try solutions listed here.

Is this something we can reasonably request the other party to upgrade their system to support, rather than downgrade our compiler?

Usually the client will strongly resist requests to upgrade their system: it's working fine for them as is, and any upgrade can break other existing applications.

If you are planning to distribute binaries on Linux (as opposed to building them on the target system), then you need to learn how to make binaries that will run everywhere, or you need to state your requirements (minimum kernel and libc versions, etc.) and turn clients who can't meet these requirements away.

Update:

Why did they get two errors. Why didn't they just get one for GLIBC_2.11.1 which is apparently what I built with?

Symbol versioning doesn't work that way.

When a new symbol is introduced, it is marked with the current libc version, e.g. readdir64@@GLIBC_2.2, posix_spawn@@GLIBC_2.15, etc.

When you link a program that uses both of the above symbols, and try to run it on e.g. glibc-2.1 system, you would get two errors.

But if you link a program that doesn't use any of the above symbols, e.g.

int main() { return 0; }

then your program will just run without any errors.

Update 2:

they don't have to add both GLIBC_2.4 and GLIBC2.7 to their Linux system, do they?

No, they don't. The GLIBC_2.11 will have all the previous symbols in it. In fact, they couldn't install both glibc-2.4 and 2.7 even if they wanted to: it is quite difficult to have multiple versions installed at the same time, and impossible to have multiple versions installed in default location.

回答2:

You've built it against a version of glibc that is too new. Build it against an older version of glibc, preferably the one that they are using.