Solved

Linux, Centos 5.2 (RHEL 5), compiling live555 for X-Linux embedded, c++: Incompatable libraries

Posted on 2008-06-25
2
1,986 Views
Last Modified: 2013-12-16
My current setup looks like this.....

Host:
   : Dell D800 1.7GHZ with Centos 5.2 which is equivalent with RHEL 5.
   : Your Developer's manual indicates to install Red Hat, Mandrake, or SUSE.  Centos is made from same source as RHEL.

Target:
   : Vortex86SX with 2GB DOM
   : X-Linux from DMP vi GHOST

I have a program that I compiled on the Host with following ldd program:
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00235000)        Actual version: libstdc++.so.6.0.8
        libm.so.6 => /lib/libm.so.6 (0x007a0000)                              Actual version: libm-2.5.so
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a9c000)                Actual version: libgcc_s-4.1.2-20080102.so.1
        libc.so.6 => /lib/libc.so.6 (0x00655000)                                Actual version: libc-2.5.so
        /lib/ld-linux.so.2 (0x00633000)                                             Actual version: ld-2.5.so


So I copied...over libstdc++ and libgcc over to the Target via ftp, following the Install your program instructions.  When I run the program on the target, I get:
/usr/bin/program: error while loading shard libraries: libstdc++.so.6: cannot handle TLS data

In investigating, I found that the other libraries in the ldd are symmlinks to different versions of the libraries...for instance
   Target:
       libc.so.6 => libc-2.3.3.so
   Host:
       libc.so.6 => libc-2.5.so

The Targets versions look like this:
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00235000)        Not there....copied
        libm.so.6 => /lib/libm.so.6 (0x007a0000)                              Actual version: libm-2.3.3.so
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a9c000)                Not there...copied
        libc.so.6 => /lib/libc.so.6 (0x00655000)                                Actual version: libc-2.3.3.so
        /lib/ld-linux.so.2 (0x00633000)                                             Actual version: ld-2.3.3.so

I am pretty sure that just copying these other libraries will fix the problem with the program I wrote, but won't it break the programs on the target?  I don't want to break them...

Recall the target is running X-Linux 2.54 http://www.dmp.com.tw/tech/os-xlinux/ so I can't really upgrade this so I will have to find a way to compile on the Centos Host machine and then transfer exe to the Target.

How do I get the appropriate libstdc++.so.6 and libgcc_s.so.1 that match up with the already existing other libraries on the Target.  How do I compile against these libraries...I don't want to break the Host either by "downgrading".  I am pretty sure the Host machine would become unusable with all those old versions.

Thanks in advance.
0
Comment
Question by:javatexan
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
2 Comments
 
LVL 9

Expert Comment

by:e-tsik
ID: 21907248
Hi :-)

I know this problem, but from another direction - when I try to ship a glibc along with the executable and redirect the library using LD_LIBRARY_PATH .
tls is threading method introduced by later GCCs. GCC can compile and/or link against the TLS version of glibc or the non-tls version. LD also has to be able to link to the proper version on the other side.
Using CentOS 4, your GCC is 4 . If sending a glibc would not work then you can either make GCC not compile tls code for you (man gcc ?) .
I googled and saw some references to a GCC bug. Here is the one I think is most relevant:
http://www.mail-archive.com/debian-gcc@lists.debian.org/msg18769.html

Hope this helps
:-)
0
 

Accepted Solution

by:
javatexan earned 0 total points
ID: 21928024
I found an answer.  First off I had to find a distro that was binary compatable.  I had to find a version of Centos that had closer versions of the common libraries, if not older than the X-Linux had.  After installing Centos version 4 and 3 on two separate VMs, I found Centos 3.9 to be slightly older than the target.  In fact it was one rev older on each of the common libraries.  

Then I recompiled my code in Centos 3.9 and hoped that it did not rely upon newer features of C++ and such...I lucked out.  Then I copied the binaries and libraries over to the target and voila.  Working system.

The boss didn't like using a really old version b/c of security fixes etc....so now I have to figure out how to cross compile and create a host/target system, building kernels and the whole nine yards :P.
0

Featured Post

Visualize your virtual and backup environments

Create well-organized and polished visualizations of your virtual and backup environments when planning VMware vSphere, Microsoft Hyper-V or Veeam deployments. It helps you to gain better visibility and valuable business insights.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

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é.
Fine Tune your automatic Updates for Ubuntu / Debian
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Learn how to navigate the file tree with the shell. Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…

726 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