5

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 <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
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?

tshepang
  • 12,111
  • 21
  • 91
  • 136
Doug Lerner
  • 1,383
  • 2
  • 17
  • 36
  • You might want to ask this on http://askubuntu.com/, or see this related question. http://askubuntu.com/q/103995/59427. – David Nehme May 16 '12 at 03:47

3 Answers3

8

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.

Community
  • 1
  • 1
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Oh, I see. Because of the error message itself, referring to GLIBC_2.4 and GLIBC_2.7 not being found. Duh. :) I will look over the solutions recommended in the link. Is this something we can reasonably request the other party to upgrade their system to support, rather than downgrade our compiler? Thanks! – Doug Lerner May 15 '12 at 09:49
  • It's an interesting dilemma. Presumably the newer glibc versions are improvements over the older ones - quicker, less buggy, etc. I hate to have to maintain multiple versions. And I would also hate to release something aimed at the least common denominator and get possibly less performance. Not to mention re-testing all the features for older libraries. This isn't a mass-market app, so maybe it is ok in this case to ask the client to upgrade to a version of Linux where the app has been tested thoroughly. Otherwise it's hard to provide proper support. Thanks! – Doug Lerner May 15 '12 at 13:42
  • I have one quick followup question if anybody sees this! Why did the user get TWO error messages: one for GLIBC_2.4 and the other for GLIBC_2.7. Why didn't they just get one for GLIBC_2.11.1 which is apparently what I built with? Thanks. Doug – Doug Lerner May 17 '12 at 00:59
  • Thanks for your further response. I don't understand this system very well, but it seems if I reply here you see it. I don't receive any notifications though, so just check back. ANYWAY... I'm embarrassed to say I don't fully understand your answer. But if the user upgrades their library to GLIBC_2.11.1 or greater would that, by backwards compatibility, avoid them seeing both errors? In other words, they don't have to add both GLIBC_2.4 and GLIBC2.7 to their Linux system, do they? Thanks again. – Doug Lerner May 17 '12 at 03:40
1

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.

Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
  • But how to link against older version of glibc? Do I need to install the old version of glibc? Can different versions of glibc coexist in the same system? – linquize Aug 14 '12 at 10:38
0

you need to build on a system that uses same versions of libraries as you do. This is where docker and VM's are very convenient. There is probably a pre-made docker image for whatever version the customer has.

Matthew Clark
  • 1