Solved

version `GLIBC_2.4' not found error

Posted on 2007-04-07
21
14,666 Views
Last Modified: 2012-08-13
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.
0
Comment
Question by:KurtVon
  • 9
  • 6
  • 5
  • +1
21 Comments
 
LVL 17

Expert Comment

by:rstaveley
ID: 18869979
0
 
LVL 4

Expert Comment

by:Kooroo
ID: 18870065
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.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 18875664
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*
0
 
LVL 11

Author Comment

by:KurtVon
ID: 18875665
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.
0
 
LVL 11

Author Comment

by:KurtVon
ID: 18875985
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.
0
 
LVL 17

Expert Comment

by:rstaveley
ID: 18878048
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.
0
 
LVL 11

Author Comment

by:KurtVon
ID: 18878392
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.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 18879074
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
0
 
LVL 11

Author Comment

by:KurtVon
ID: 18880064
Unfortunately, libc.so.5 is not a symbolic link and gcc is not on the embedded system.  Any other ways to narrow it down?
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 18881252
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.
0
Complete VMware vSphere® ESX(i) & Hyper-V Backup

Capture your entire system, including the host, with patented disk imaging integrated with VMware VADP / Microsoft VSS and RCT. RTOs is as low as 15 seconds with Acronis Active Restore™. You can enjoy unlimited P2V/V2V migrations from any source (even from a different hypervisor)

 
LVL 11

Author Comment

by:KurtVon
ID: 18882188
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 (0xb7c1c000)
        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.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 18886008
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.
0
 
LVL 17

Expert Comment

by:rstaveley
ID: 18887875
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.
0
 
LVL 11

Author Comment

by:KurtVon
ID: 18891226
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?
0
 
LVL 11

Author Comment

by:KurtVon
ID: 18892325
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.
0
 
LVL 34

Accepted Solution

by:
Duncan Roe earned 400 total points
ID: 18894096
Ok so the target is a 686 - you can upgrade it by copying libraries off the development system. I know I implied it was tricky but it starts to look like the easiest option.
Before you start, make sure the target system has sln:

08:01:06$ file `type -p sln`
/bin/sln: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

sln is a statically-linked version of the ln command which always makes symbolic links. You shouldn't need it, but it can get you out of trouble.

On the BUILD system, determine the exact rev of libc.so.6 by following symlinks using ls -l
Make a list of what files to copy with this rev. Here's an example from my system:

08:11:41$ ls -l libc.so.6
lrwxrwxrwx  1 root root 13 2006-05-21 11:33 libc.so.6 -> libc-2.3.6.so

08:14:09$ find . -name '*2.3.6*' -print
./libc-2.3.6.so
./ld-2.3.6.so
./libm-2.3.6.so
./libdl-2.3.6.so
./libcidn-2.3.6.so
./libcrypt-2.3.6.so
./libanl-2.3.6.so
./librt-2.3.6.so
./libnsl-2.3.6.so
./libBrokenLocale-2.3.6.so
./libpthread-2.3.6.so
./libnss_files-2.3.6.so
./libresolv-2.3.6.so
./libnss_dns-2.3.6.so
./libnss_hesiod-2.3.6.so
./libutil-2.3.6.so
./libnss_nis-2.3.6.so
./libnss_nisplus-2.3.6.so
./libnss_compat-2.3.6.so

That's your list. Do the same on the TARGET system. For example, my 32-bit partition:

08:18:35$ ls -l libc.so.6
lrwxr-xr-x  1 root root 13 2004-11-07 20:00 libc.so.6 -> libc-2.3.3.so

08:20:53$ find . -name '*2.3.3*' -print
./i686/libc-2.3.3.so
./i686/libm-2.3.3.so
./i686/librt-2.3.3.so
./libBrokenLocale-2.3.3.so
./ld-2.3.3.so
./tls/libc-2.3.3.so
./tls/libm-2.3.3.so
./tls/librt-2.3.3.so
./libNoVersion-2.3.3.so
./libanl-2.3.3.so
./libc-2.3.3.so
./libcidn-2.3.3.so
./libcrypt-2.3.3.so
./libdl-2.3.3.so
./libm-2.3.3.so
./libnsl-2.3.3.so
./libnss1_compat-2.3.3.so
./libnss1_dns-2.3.3.so
./libnss1_files-2.3.3.so
./libnss1_nis-2.3.3.so
./libnss_compat-2.3.3.so
./libnss_dns-2.3.3.so
./libnss_files-2.3.3.so
./libnss_hesiod-2.3.3.so
./libnss_nis-2.3.3.so
./libnss_nisplus-2.3.3.so
./libresolv-2.3.3.so
./librt-2.3.3.so
./libutil-2.3.3.so

Notice there are subdirectories i686 & tls. If you find you have them on the target, you'll need to rename them as part of the upgrade (to tls.old & i686.old say).

NB Never overwrite anything! Always rename (or delete, but I recommend rename).

After copying everything, run ldconfig. You may have to to the ld link yourself:

08:26:33$ ls -l ld-linux.so.2
lrwxr-xr-x  1 root root 11 2004-11-07 20:00 ld-linux.so.2 -> ld-2.3.3.so

If ldconfig doesn't update that link, do it by hand. You'll know if it didn't, because nothing will work (except sln:)

Must go now - post if you have any questions
0
 
LVL 17

Expert Comment

by:rstaveley
ID: 18896008
If you install KDevelop on a Debian 3.1 ("sarge") virtual machine, its defaults should be right for you.
0
 
LVL 17

Expert Comment

by:rstaveley
ID: 18896045
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.
0
 
LVL 11

Author Comment

by:KurtVon
ID: 18898791
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.
0
 
LVL 17

Assisted Solution

by:rstaveley
rstaveley earned 100 total points
ID: 18899614
If you are getting GCC_4.2.0 not found, it means you've still got something in your link that depends on a GCC 4.2 shared library (i.e. you've not succeeded in doing a GCC 3.3 build).

Assuming your deployment system is Debian 3.1 ("sarge"), if you look at the GCC symbols in libgcc_s.so.1, you'll see:

$ strings /lib/libgcc_s.so.1 |grep GCC
GCC_3.0
GCC_3.3
GCC_3.3.1
GCC_3.4
GCC_3.4.2

i.e. no GCC_4.2.0.

That's your culprit, I expect. I guess that's the shared library you want to replace, if that's what you want to do... but my instincts say that you'll have moe work going that route than VM.

I shouldn't be wary about developing with Debian 3.1. It is only 2 years old and of course stable. My preferred ISP still installs a Debian 3.1 base on new dedicated systems, using "pinning" to allow new hardware support.

I was recommended backports.org for installing new software on Debian stable branches. Apparently, you should look at sarge-backports - see http://www.backports.org/dokuwiki/doku.php?id=instructions - but I've not looked into it myself. It is conceivable that you can get GCC 4.2 onto the deployment system that way.
0
 
LVL 11

Author Comment

by:KurtVon
ID: 18900361
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.
0

Featured Post

Backup Your Microsoft Windows Server®

Backup all your Microsoft Windows Server – on-premises, in remote locations, in private and hybrid clouds. Your entire Windows Server will be backed up in one easy step with patented, block-level disk imaging. We achieve RTOs (recovery time objectives) as low as 15 seconds.

Join & Write a Comment

Suggested Solutions

Using 'screen' for session sharing, The Simple Edition Step 1: user starts session with command: screen Step 2: other user (logged in with same user account) connects with command: screen -x Done. Both users are connected to the same CLI sessio…
It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
Learn several ways to interact with files and get file information from the bash shell. ls lists the contents of a directory: Using the -a flag displays hidden files: Using the -l flag formats the output in a long list: The file command gives us mor…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now