KurtVon
asked on
version `GLIBC_2.4' not found error
I'm compiling my C++ program under Ubuntu 6.10 using KDevelop. Unfortunately, it needs to run on an embedded device with no compiler running Debian. I get the error "version `GLIBC_2.4' not found" and "version `GCC_4.2.0' not found" when I try.
Now, I'm not stupid. Obviously the compiler on the new dev machine uses glibc 2.4. The problem is I can not put a compiler on the target machine. I can add libraries, but I can't replace them, especially not if they make the existing software stop working, so I think updating glibc on the target is right out too.
Unless there is a solution I'm not thinking of, I'm going to need to know how to do one of the following:
1. Make ubuntu compile using an older version of gcc and glibc
2. Make ubuntu compile self-contained programs that won't need the external glibc libraries
3. Add glibc 2.4 and gcc 4.2 libraries to the Debian system without overwriting any of the existing libraries.
Any help to do any of these (or a better solution altogether) would be appreciated. Thanks.
Now, I'm not stupid. Obviously the compiler on the new dev machine uses glibc 2.4. The problem is I can not put a compiler on the target machine. I can add libraries, but I can't replace them, especially not if they make the existing software stop working, so I think updating glibc on the target is right out too.
Unless there is a solution I'm not thinking of, I'm going to need to know how to do one of the following:
1. Make ubuntu compile using an older version of gcc and glibc
2. Make ubuntu compile self-contained programs that won't need the external glibc libraries
3. Add glibc 2.4 and gcc 4.2 libraries to the Debian system without overwriting any of the existing libraries.
Any help to do any of these (or a better solution altogether) would be appreciated. Thanks.
rstaveley
You could link statically - see http://www.faqs.org/docs/linux_scratch/chapter05/whystatic.html
you can put the libraries on the target system and then set your LDFLAGS and CPPFLAGS to point to the appropriate directories in order to compile your program.
Have a look at trhe embedded system to see what revs are installed, e.g
23:32:16$ ls -l /lib/libc.so*
lrwxr-xr-x 1 root root 14 2005-01-30 17:52 /lib/libc.so.5 -> libc.so.5.4.44
-rwxr-xr-x 1 root root 2178190 1998-02-22 02:16 /lib/libc.so.5.4.44
lrwxr-xr-x 1 root root 13 2004-11-07 20:00 /lib/libc.so.6 -> libc-2.3.3.so
23:33:09$ gcc --version
gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Likely you can find an older distro with the required revs to install on a spare system. Then build on that system. If it's a simple matter to upgrade the embedded one, by all means do so.
Another possibility is to use an older live CD to do the build - could be attractive if you don't have a spare old system.
Downgrading the libc your system came with would very likely break it. Upgrading the embedded system is safer, if you can find a build for the architecture.
Static linking will give you a huge executable:
23:41:49$ gcc hello.c -static -o hello
23:42:12$ ls -l hello
-rwxr-xr-x 1 dunc users 5655308 2007-04-09 23:42 hello*
23:32:16$ ls -l /lib/libc.so*
lrwxr-xr-x 1 root root 14 2005-01-30 17:52 /lib/libc.so.5 -> libc.so.5.4.44
-rwxr-xr-x 1 root root 2178190 1998-02-22 02:16 /lib/libc.so.5.4.44
lrwxr-xr-x 1 root root 13 2004-11-07 20:00 /lib/libc.so.6 -> libc-2.3.3.so
23:33:09$ gcc --version
gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Likely you can find an older distro with the required revs to install on a spare system. Then build on that system. If it's a simple matter to upgrade the embedded one, by all means do so.
Another possibility is to use an older live CD to do the build - could be attractive if you don't have a spare old system.
Downgrading the libc your system came with would very likely break it. Upgrading the embedded system is safer, if you can find a build for the architecture.
Static linking will give you a huge executable:
23:41:49$ gcc hello.c -static -o hello
23:42:12$ ls -l hello
-rwxr-xr-x 1 dunc users 5655308 2007-04-09 23:42 hello*
ASKER
Static linking would be option 2, but there doesn't seem to be any flags to set to actually do it. Unfortunately, the link just talks about how great static linking is without really saying how to make it happen. I can't seem to find any hints through google either.
ASKER
I most likely can't upgrade the embedded system. It contains a large number of custom utilities that rely on the older glibc and do not provide source code.
If there is some way to get both libraries on the system and linking the right way, that would work. A huge executable isn't that big a deal, though. I'm only running two programs of my own.
If there is some way to get both libraries on the system and linking the right way, that would work. A huge executable isn't that big a deal, though. I'm only running two programs of my own.
You tried using the -static flag?
See the gcc man page:
-static
On systems that support dynamic linking, this prevents linking with
the shared libraries. On other systems, this option has no effect.
You can check that it works by running ldd on your executable, which, as Duncan pointed out, you expect to be large.
See the gcc man page:
-static
On systems that support dynamic linking, this prevents linking with
the shared libraries. On other systems, this option has no effect.
You can check that it works by running ldd on your executable, which, as Duncan pointed out, you expect to be large.
ASKER
I tried setting the -static flag in the linker section, and used the automake window to select the bin file, then configured by checking the "do not link against shared libraries" option. Neither one actually produced a statically linked executable.
I also tried importing the project into Eclipse with equal lack of luck on finding any kind of option for static linking.
The project is a bit large to be compiled by hand, but if I had to use the make file I could mess with it. I have checked and the keyword "static" does not appear anywhere in it no matter how many times it is in the confguration for the project.
KDevelop is a pretty nice development environment, but what it lacks in documentation it more than makes up for with bizarre unexpected behavior.
I also tried importing the project into Eclipse with equal lack of luck on finding any kind of option for static linking.
The project is a bit large to be compiled by hand, but if I had to use the make file I could mess with it. I have checked and the keyword "static" does not appear anywhere in it no matter how many times it is in the confguration for the project.
KDevelop is a pretty nice development environment, but what it lacks in documentation it more than makes up for with bizarre unexpected behavior.
It's actually unlikely that the apps on the embedded system "rely" on the older glibc: glibc usualyy has a degree of backwards compatibility settable at configure time. Just what rev is installed on the embedded system now - can you post that? See my earlier post for how to find out what it is. Fo instance, if it's 2.3.something then you should be OK to upgrade to 2.4.
The GCC_ symbols are in libgcc_s.so, usually found in /lib. An upgrade should fix, but you might want to check you don't lose any old GCC symbiols. On my system:
08:24:43$ strings /lib64/libgcc_s.so.1 |grep GCC
GCC_3.0
GCC_3.3
GCC_3.3.1
GCC_3.4
The GCC_ symbols are in libgcc_s.so, usually found in /lib. An upgrade should fix, but you might want to check you don't lose any old GCC symbiols. On my system:
08:24:43$ strings /lib64/libgcc_s.so.1 |grep GCC
GCC_3.0
GCC_3.3
GCC_3.3.1
GCC_3.4
ASKER
Unfortunately, libc.so.5 is not a symbolic link and gcc is not on the embedded system. Any other ways to narrow it down?
libc.so.5 is *old* - very different from any libc6. Is that the latest it has? How old is the OS? (i.e. what's the linux rev?). While we're at it, what is the architecture?
As long as the embedded system has the necessary disk spave, there is no problem at all installing libc6 (glibc2.x) alongside it. I have that setup in my 32-bit partition's /lib (I even have libc.so.4 for the old a.out pre-ELF format binaries). They all coexist, and don't interact. But you'll need *every* library your app uses - ldd will tell you what these are.
As long as the embedded system has the necessary disk spave, there is no problem at all installing libc6 (glibc2.x) alongside it. I have that setup in my 32-bit partition's /lib (I even have libc.so.4 for the old a.out pre-ELF format binaries). They all coexist, and don't interact. But you'll need *every* library your app uses - ldd will tell you what these are.
ASKER
It's i386 using Linux 2.6.8.2 on Debian 1:3.3.5-13
I have libc.so.6 symbolically linked to libc.so.6.0.8
ldd says
/lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /usr/lib/libstdc++.so.6)
/lib/libgcc-s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)
libxerces-c.so.27 => /usr/lib/libxerces-c.so.27
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7b3c000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7b1a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7b11000)
libc.so.6 => /lib/tls/libc.so.6 (0xb79dc000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb79cd000)
libicuuc.so.34 => /usr/lib/libicuuc.so.34 (0xb78cb000)
libicudata.so.34 => /usr/lib/libicudata.so.34 (0xb7055000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fe5000)
libc.so.6 links to libc-2.3.2.so and libgcc_s.so.1 exists as an ordinary file.
I have libc.so.6 symbolically linked to libc.so.6.0.8
ldd says
/lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /usr/lib/libstdc++.so.6)
/lib/libgcc-s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)
libxerces-c.so.27 => /usr/lib/libxerces-c.so.27
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7b3c000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7b1a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7b11000)
libc.so.6 => /lib/tls/libc.so.6 (0xb79dc000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb79cd000)
libicuuc.so.34 => /usr/lib/libicuuc.so.34 (0xb78cb000)
libicudata.so.34 => /usr/lib/libicudata.so.34 (0xb7055000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fe5000)
libc.so.6 links to libc-2.3.2.so and libgcc_s.so.1 exists as an ordinary file.
Ok you *do* have libc.so.6. Can you post the ldd on the build system as well please, and check whether libgcc_s.so.1 is a regular file there as well or a symlink. (on my system it's a symlink).
Is this a genuine 80386 btw? the 486 doesn't need a fan either so I'd have expected one of those, unless maybe you don't have a math co-processor either?
The point being, you need to get libraries built for the processor (e.g. really an i386 glibc, not i586 &c.). You are doing that when you configure the app before you build it (aren't you?).
Upgrading the libraries by hand is do-able if you know what you're doing, but if you knew enough to do that then you wouldn't be asking, right? There are lots of little pitfalls (tls/ goes away and *must* be [re]moved, you should really have a kernel >2.6.15.1, ...) so let's put that option aside for now.
You might get the static build to work by changing LDFLAGS or CFLAGS (i.e. tell configure what to use). But unless your system libraries are built for the target (386), you'll run into that problem (app might start but will get illega; instrn when it tries to use an opcode you haven't got).
All in all, the best option seems to me to build in an environment at the same or a lower rev than the target. That's a good rule for build environments in general.
Is this a genuine 80386 btw? the 486 doesn't need a fan either so I'd have expected one of those, unless maybe you don't have a math co-processor either?
The point being, you need to get libraries built for the processor (e.g. really an i386 glibc, not i586 &c.). You are doing that when you configure the app before you build it (aren't you?).
Upgrading the libraries by hand is do-able if you know what you're doing, but if you knew enough to do that then you wouldn't be asking, right? There are lots of little pitfalls (tls/ goes away and *must* be [re]moved, you should really have a kernel >2.6.15.1, ...) so let's put that option aside for now.
You might get the static build to work by changing LDFLAGS or CFLAGS (i.e. tell configure what to use). But unless your system libraries are built for the target (386), you'll run into that problem (app might start but will get illega; instrn when it tries to use an opcode you haven't got).
All in all, the best option seems to me to build in an environment at the same or a lower rev than the target. That's a good rule for build environments in general.
I reckon you should consider using a virtual machine for the build. You can set it up as an i386 with Debian 3.1 on it. It is probably much less hassle than getting i386 libraries and installing GCC-3.3 on your Ubunti development box and figuring out how to set up KDevelop to use non-defaults.
ASKER
libgcc_s.so.1 exists on the development machine and is not a symlink.
The embedded device is actually a dual-core Intel Xeon 3.6GHz processor, but the final unit will be a P4 1.6GHz (the test machine is way overpowered).
I still have the old redhat system we used to develop on, but that is on its last legs, so I was really hoping to upgrade. It's a laptop and the batteries work fine, but the charger works most infrequently.
According to the package manager, I do have gcc 3.3 installed. So the trick is to get the #%$^#$ KDevelop to use it. Is there a separate compiler command? What would happen if I just changed the gcc symlink to gcc-3.4?
The embedded device is actually a dual-core Intel Xeon 3.6GHz processor, but the final unit will be a P4 1.6GHz (the test machine is way overpowered).
I still have the old redhat system we used to develop on, but that is on its last legs, so I was really hoping to upgrade. It's a laptop and the batteries work fine, but the charger works most infrequently.
According to the package manager, I do have gcc 3.3 installed. So the trick is to get the #%$^#$ KDevelop to use it. Is there a separate compiler command? What would happen if I just changed the gcc symlink to gcc-3.4?
ASKER
Well, using g++-3.3 as the compiler produced an executable, but I got the exact same errors as I had initially. Obviously there is something more than just the compiler choice. There don't seem to be any real options for selecting libraries, either.
The problem with creating a VM is what do i install on it? The only thing I've ever gotten to work is the redhat I don't have installation disks for.
The problem with creating a VM is what do i install on it? The only thing I've ever gotten to work is the redhat I don't have installation disks for.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If you install KDevelop on a Debian 3.1 ("sarge") virtual machine, its defaults should be right for you.
If you get no joy for Debia 3.1, I guess you need to look at /etc/redhat-release to find out the RedHat version and find its ISO to download (broadband!). Easy if it is a Fedora Core... I'm not sure where you get pre-Fedora RedHat ISOs, but I'm sure an expert in the Linux TAs will be able to point you.
ASKER
Okay, didn't have sln so I just backed up the hard drive. The technique seems to have solved the GLIBC error (I rebooted just to be sure and even the old stuff still runs) but I'm still having trouble with the "`GCC_4.2.0' not found" error.
I looked into it and saw libstdc++.so.6 points to libstdc++.so.6.0.8 on both systems. There aren't any other libraries marked version "6.0.8" so I'm not sure what needs to be copied (if anything can be). The package manager doesn't list any support files either.
And the real source of my nervousness about using a VM is that it gives me the willies to think that I have to rely on an older OS just to compile the programs. I guess I'm a bit old fashioned about it, but I like having a little more stability in my development process.
I looked into it and saw libstdc++.so.6 points to libstdc++.so.6.0.8 on both systems. There aren't any other libraries marked version "6.0.8" so I'm not sure what needs to be copied (if anything can be). The package manager doesn't list any support files either.
And the real source of my nervousness about using a VM is that it gives me the willies to think that I have to rely on an older OS just to compile the programs. I guess I'm a bit old fashioned about it, but I like having a little more stability in my development process.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hey, that did it! And it seems to be backwards compatible since it survived a reboot.
Sorry for repeatedly dismissing teh VM solution. While it is elegant, I'm not concerned with stability but portability. Handing off my code to someone else is going to cause untold problems if they have to install a certain version of linux or a VM with some tricky whatever. I was looking for a solution that would compile the program correctly.
There was also the issue of what happens when updates come out. With any luck they won't be horrific on the compiler, especially using a stable version of debian in a VM, but when I need some new feature due to management request, I'm screwed. And updates to the embedded system are also an issue (they will continue to update for a few more years at least).
I left Windows to get away from these annoyances, not revisit them in a new and intriguing way.
But thanks to both of you for getting me through this rather nasty issue.
Sorry for repeatedly dismissing teh VM solution. While it is elegant, I'm not concerned with stability but portability. Handing off my code to someone else is going to cause untold problems if they have to install a certain version of linux or a VM with some tricky whatever. I was looking for a solution that would compile the program correctly.
There was also the issue of what happens when updates come out. With any luck they won't be horrific on the compiler, especially using a stable version of debian in a VM, but when I need some new feature due to management request, I'm screwed. And updates to the embedded system are also an issue (they will continue to update for a few more years at least).
I left Windows to get away from these annoyances, not revisit them in a new and intriguing way.
But thanks to both of you for getting me through this rather nasty issue.