gcc compatibility

gcc compatibility

[cdinesh]

Properly
Strike
Protest

 Hi 

    I have two  Linux systems  have different gcc  version 
          system A  -> gcc  (3.4.4)
          system B  -> gcc  (4.1.2)


  I would like to build test program that can be run on both systems 
  ---------------------------
  #include <stdio.h>
  main(){
   printf("hello world \n");
  }
  ---------------------------
   gcc test.c -o test

  ldd on system A 
         linux-gate.so.1 =>  (0x00d42000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00b0c000)
        /lib/ld-linux.so.2 (0x00af2000)

  ldd on system B 
         linux-gate.so.1 =>  (0x00814000)
        libc.so.6 => /lib/libc.so.6 (0x0054a000)
        /lib/ld-linux.so.2 (0x0052d000)

   Test case 1 
     Build test.c on system A and run on both systems A and B. 
           on sytem A     ok
            on system B    ok.

   Test case 2 
     Build test.c on system B and run on both systems A and B. 
             on system B   ok
             on system A   error
           error log 
             # ./test
              Floating point exception

             # ldd 
             /usr/bin/ldd: line 124:  3911 Floating pointexception
LD_TRACE_LOADED_OBJECTS=1 LD_WARN= 
             LD_BIND_NOW= LD_LIBRARY_VERSION
 =$verify_out LD_VERBOSE= "$@"
 
    for other information 

      System A 
            kernel  2.6.12
            gliibc version  2.3.6
            binutils  2.15.92.0.2
            selinux disable

      System B 
            kernel  2.6.18
            gliibc version  2.5
            binutils  2.17.50.0.6
            selinux disable


I have a feeling the problem is in the libraries. Please give any advice ?

Thank you 

-- 
View this message in context: http://www.nabble.com/gcc--compatibility-tp17396275p17396275.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: gcc compatibility

[Sven Eschenberg]

Hi there,

As you can see your program is linked against the NTPL version of glibc 
on System A (running glibc 2.3) ... LinuxThreads support was dropped in 
2.4 AFAIK. Obviously the version compiled on System B is linked against 
version 2.5 of glibc.

I can only assume that with some sort of ABI change for NPTL along with 
the newer binutils something in the resulting executeable changed in a 
way, that System A cannot properly link dynamically against the old NTPL 
interface.

You could check the outputs of your two glibc version to check for 
differences ... (Just run them), the output should somewhat look like this:

GNU C Library stable release version 2.6.1, by Roland McGrath et al.
Copyright (C) 2007 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.
Compiled by GNU CC version 4.1.2 (Gentoo 4.1.2).
Compiled on a Linux >>2.6.16.16<< system on 2007-12-08.
Available extensions:
        C stubs add-on version 2.1.2
        crypt add-on version 2.1 by Michael Glad and others
        Gentoo patchset 1.1
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        Support for some architectures added on, not maintained in glibc 
core.
        BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

You could aswell inspect the two executeables (with objdump etc.) to see 
if there is a major difference in the sections or something ... and 
since you program is so short you could check the asm output before 
final linking for differences.

But I guess you might have to ask the glibc folks for the internals and 
an exact answer.

Regards

-Sven

cdinesh schrieb:
> Properly
> Strike
> Protest
>
>  Hi 
>
>     I have two  Linux systems  have different gcc  version 
>           system A  -> gcc  (3.4.4)
>           system B  -> gcc  (4.1.2)
>
>
>   I would like to build test program that can be run on both systems 
>   ---------------------------
>   #include <stdio.h>
>   main(){
>    printf("hello world \n");
>   }
>   ---------------------------
>    gcc test.c -o test
>
>   ldd on system A 
>          linux-gate.so.1 =>  (0x00d42000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x00b0c000)
>         /lib/ld-linux.so.2 (0x00af2000)
>
>   ldd on system B 
>          linux-gate.so.1 =>  (0x00814000)
>         libc.so.6 => /lib/libc.so.6 (0x0054a000)
>         /lib/ld-linux.so.2 (0x0052d000)
>
>    Test case 1 
>      Build test.c on system A and run on both systems A and B. 
>            on sytem A     ok
>             on system B    ok.
>
>    Test case 2 
>      Build test.c on system B and run on both systems A and B. 
>              on system B   ok
>              on system A   error
>            error log 
>              # ./test
>               Floating point exception
>
>              # ldd 
>              /usr/bin/ldd: line 124:  3911 Floating pointexception
> LD_TRACE_LOADED_OBJECTS=1 LD_WARN= 
>              LD_BIND_NOW= LD_LIBRARY_VERSION
>  =$verify_out LD_VERBOSE= "$@"
>  
>     for other information 
>
>       System A 
>             kernel  2.6.12
>             gliibc version  2.3.6
>             binutils  2.15.92.0.2
>             selinux disable
>
>       System B 
>             kernel  2.6.18
>             gliibc version  2.5
>             binutils  2.17.50.0.6
>             selinux disable
>
>
> I have a feeling the problem is in the libraries. Please give any advice ?
>
> Thank you 
>
>   

Re: gcc compatibility

[cdinesh]

 Thank you Sven for quick response
  
>>  As you can see your program is linked against the NTPL version of glibc 
>> on System A (running glibc 2.3) ... LinuxThreads support was dropped in 
>> 2.4 AFAIK. Obviously the version compiled on System B is linked against 
>> version 2.5 of glibc.
Correct both have different thread  versions

>>You could check the outputs of your two glibc version to check for 
>>differences ... (Just run them), the output should somewhat look like
this:
yaa , correct  but  is there any compile option  in gcc that can ignore
glibc versions or ABI changes ??

 Is there any problem in "linux-gate.so.1" ??

thank you 
dinesh
 


Sven Eschenberg wrote:
> 
> Hi there,
> 
> As you can see your program is linked against the NTPL version of glibc 
> on System A (running glibc 2.3) ... LinuxThreads support was dropped in 
> 2.4 AFAIK. Obviously the version compiled on System B is linked against 
> version 2.5 of glibc.
> 
> I can only assume that with some sort of ABI change for NPTL along with 
> the newer binutils something in the resulting executeable changed in a 
> way, that System A cannot properly link dynamically against the old NTPL 
> interface.
> 
> You could check the outputs of your two glibc version to check for 
> differences ... (Just run them), the output should somewhat look like
> this:
> 
> GNU C Library stable release version 2.6.1, by Roland McGrath et al.
> Copyright (C) 2007 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.
> Compiled by GNU CC version 4.1.2 (Gentoo 4.1.2).
> Compiled on a Linux >>2.6.16.16<< system on 2007-12-08.
> Available extensions:
>         C stubs add-on version 2.1.2
>         crypt add-on version 2.1 by Michael Glad and others
>         Gentoo patchset 1.1
>         GNU Libidn by Simon Josefsson
>         Native POSIX Threads Library by Ulrich Drepper et al
>         Support for some architectures added on, not maintained in glibc 
> core.
>         BIND-8.2.3-T5B
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/libc/bugs.html>.
> 
> You could aswell inspect the two executeables (with objdump etc.) to see 
> if there is a major difference in the sections or something ... and 
> since you program is so short you could check the asm output before 
> final linking for differences.
> 
> But I guess you might have to ask the glibc folks for the internals and 
> an exact answer.
> 
> Regards
> 
> -Sven
> 
> cdinesh schrieb:
>> Properly
>> Strike
>> Protest
>>
>>  Hi 
>>
>>     I have two  Linux systems  have different gcc  version 
>>           system A  -> gcc  (3.4.4)
>>           system B  -> gcc  (4.1.2)
>>
>>
>>   I would like to build test program that can be run on both systems 
>>   ---------------------------
>>   #include <stdio.h>
>>   main(){
>>    printf("hello world \n");
>>   }
>>   ---------------------------
>>    gcc test.c -o test
>>
>>   ldd on system A 
>>          linux-gate.so.1 =>  (0x00d42000)
>>         libc.so.6 => /lib/tls/libc.so.6 (0x00b0c000)
>>         /lib/ld-linux.so.2 (0x00af2000)
>>
>>   ldd on system B 
>>          linux-gate.so.1 =>  (0x00814000)
>>         libc.so.6 => /lib/libc.so.6 (0x0054a000)
>>         /lib/ld-linux.so.2 (0x0052d000)
>>
>>    Test case 1 
>>      Build test.c on system A and run on both systems A and B. 
>>            on sytem A     ok
>>             on system B    ok.
>>
>>    Test case 2 
>>      Build test.c on system B and run on both systems A and B. 
>>              on system B   ok
>>              on system A   error
>>            error log 
>>              # ./test
>>               Floating point exception
>>
>>              # ldd 
>>              /usr/bin/ldd: line 124:  3911 Floating pointexception
>> LD_TRACE_LOADED_OBJECTS=1 LD_WARN= 
>>              LD_BIND_NOW= LD_LIBRARY_VERSION
>>  =$verify_out LD_VERBOSE= "$@"
>>  
>>     for other information 
>>
>>       System A 
>>             kernel  2.6.12
>>             gliibc version  2.3.6
>>             binutils  2.15.92.0.2
>>             selinux disable
>>
>>       System B 
>>             kernel  2.6.18
>>             gliibc version  2.5
>>             binutils  2.17.50.0.6
>>             selinux disable
>>
>>
>> I have a feeling the problem is in the libraries. Please give any advice
>> ?
>>
>> Thank you 
>>
>>   
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/gcc--compatibility-tp17396275p17397451.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: gcc compatibility

[Sven Eschenberg]

Hi Dinesh,

Well it is fairly normal to run into problems when trying to run a 
progam with old libs, if it was linked to newer ones.

If there is a command line switch, it's rather related to ld (the 
linker) whose switches of course can be passed to gcc.

To find out which switch might help and why exactly the old glibc's 
dynamic linker doesn't like the executeable from system B, you can try 
the following:

set LD_DEBUG to all (export LD_DEBUG="all")

Then run your program, and see if the linker spits out something where 
exactly the problem occurs (maybe you are lucky)

One issue could be the .hash versus .gnu.hash section ... I don't know 
when this was changed. But as long as we do not know what the linker was 
trying to do, when it crashed, it will be hard to see, if the problem 
can be fixed by a commandline switch.

Regards

-Sven

P.S.: To answer your previous gate.so question - It is a virtual shared 
object which maps the kernel's syscall interface into the proces' memory 
map ... I doubt this causes the linker to go nuts ...

>  Thank you Sven for quick response
>   
>   
>>>  As you can see your program is linked against the NTPL version of glibc 
>>> on System A (running glibc 2.3) ... LinuxThreads support was dropped in 
>>> 2.4 AFAIK. Obviously the version compiled on System B is linked against 
>>> version 2.5 of glibc.
>>>       
> Correct both have different thread  versions
>
>   
>>> You could check the outputs of your two glibc version to check for 
>>> differences ... (Just run them), the output should somewhat look like
>>>       
> this:
> yaa , correct  but  is there any compile option  in gcc that can ignore
> glibc versions or ABI changes ??
>
>  Is there any problem in "linux-gate.so.1" ??
>
> thank you 
> dinesh
>  
>   

Re: gcc compatibility

[cdinesh]

 Hi Sven

 I have tried with  set LD_DEBUG  on system A .
 The binary is looking  for libc and ld-linux librarys and 
 while loading them on system A  ld  has some problem.
 as of your reference ld checking  hashing type also  (.hash or .gnuhash)

now Iam planning to copy system B libraries ( mainly glibc-2.5) to system A 
at some location 
(i.e /usr/local/lib-2.5 ) and while building binary on system B  and give 
-L /usr/local/lib-2.5 

Is there any other processor ??

regards
dinesh



Sven Eschenberg wrote:
> 
> Hi Dinesh,
> 
> Well it is fairly normal to run into problems when trying to run a 
> progam with old libs, if it was linked to newer ones.
> 
> If there is a command line switch, it's rather related to ld (the 
> linker) whose switches of course can be passed to gcc.
> 
> To find out which switch might help and why exactly the old glibc's 
> dynamic linker doesn't like the executeable from system B, you can try 
> the following:
> 
> set LD_DEBUG to all (export LD_DEBUG="all")
> 
> Then run your program, and see if the linker spits out something where 
> exactly the problem occurs (maybe you are lucky)
> 
> One issue could be the .hash versus .gnu.hash section ... I don't know 
> when this was changed. But as long as we do not know what the linker was 
> trying to do, when it crashed, it will be hard to see, if the problem 
> can be fixed by a commandline switch.
> 
> Regards
> 
> -Sven
> 
> P.S.: To answer your previous gate.so question - It is a virtual shared 
> object which maps the kernel's syscall interface into the proces' memory 
> map ... I doubt this causes the linker to go nuts ...
> 
>>  Thank you Sven for quick response
>>   
>>   
>>>>  As you can see your program is linked against the NTPL version of
>>>> glibc 
>>>> on System A (running glibc 2.3) ... LinuxThreads support was dropped in 
>>>> 2.4 AFAIK. Obviously the version compiled on System B is linked against 
>>>> version 2.5 of glibc.
>>>>       
>> Correct both have different thread  versions
>>
>>   
>>>> You could check the outputs of your two glibc version to check for 
>>>> differences ... (Just run them), the output should somewhat look like
>>>>       
>> this:
>> yaa , correct  but  is there any compile option  in gcc that can ignore
>> glibc versions or ABI changes ??
>>
>>  Is there any problem in "linux-gate.so.1" ??
>>
>> thank you 
>> dinesh
>>  
>>   
> 
> 

-- 
View this message in context: http://www.nabble.com/gcc--compatibility-tp17396275p17420841.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: gcc compatibility

[Kai Ruottu]

cdinesh wrote:

> now Iam planning to copy system B libraries ( mainly glibc-2.5) to system A 
> at some location (i.e /usr/local/lib-2.5 ) and while building binary on
 > system B  and give -L /usr/local/lib-2.5

There are two linker options for seeing the shared libraries first in
some exceptional place :

1. at link-time : -rpath-link <directory>

2. at run-time  : -rpath <directory>

So one can control where the libraries are searched from first when
linking and where they are seached first at run-time.

Basically the installed shared libraries in '/lib' and '/usr/lib'
should enable any "sanily made" application to run! It is really
unsane to expect any application made for a newer system to run
on older systems meanwhile it is perfectly sane to expect all those
apps made for older systems to run on newer systems...

In your case all apps made for (usually also 'on') the older system
A, should work on the newer system B. But never vice versa :(

The GCCs coming with the Linux distros are called "native", they are
only for building apps from sources for the native system! All apps
will be distributed as sources, this is the goal in "open source".
If one needs to produce apps for "other systems", let these be
Sparc/Solarises, Windoze/Cygwin, Windoze/MinGW, other Linuces with
other CPU-architectures or only some other distro for just the same
CPU-architecture, then one should produce the apps via "crosscompiling",
the "native compiling" cannot do that....

If people or companies would pay for or even ask these "cross
toolchains" being delivered as install packages, then surely
they would be there. At least the Debian people have asked about
possibilities to produce apps for Windoze because the MinGW-target
tools have been with this distro for a while (some years)...

Currently people like to build these things themselves, from sources
of course (binutils and GCC, the target libraries are usually pre-made
and pre-tested)...

> 
> Is there any other processor ??
> 
> regards
> dinesh
> 
> 
> 
> Sven Eschenberg wrote:
>> Hi Dinesh,
>>
>> Well it is fairly normal to run into problems when trying to run a 
>> progam with old libs, if it was linked to newer ones.
>>
>> If there is a command line switch, it's rather related to ld (the 
>> linker) whose switches of course can be passed to gcc.
>>
>> To find out which switch might help and why exactly the old glibc's 
>> dynamic linker doesn't like the executeable from system B, you can try 
>> the following:
>>
>> set LD_DEBUG to all (export LD_DEBUG="all")
>>
>> Then run your program, and see if the linker spits out something where 
>> exactly the problem occurs (maybe you are lucky)
>>
>> One issue could be the .hash versus .gnu.hash section ... I don't know 
>> when this was changed. But as long as we do not know what the linker was 
>> trying to do, when it crashed, it will be hard to see, if the problem 
>> can be fixed by a commandline switch.
>>
>> Regards
>>
>> -Sven
>>
>> P.S.: To answer your previous gate.so question - It is a virtual shared 
>> object which maps the kernel's syscall interface into the proces' memory 
>> map ... I doubt this causes the linker to go nuts ...
>>
>>>  Thank you Sven for quick response
>>>   
>>>   
>>>>>  As you can see your program is linked against the NTPL version of
>>>>> glibc 
>>>>> on System A (running glibc 2.3) ... LinuxThreads support was dropped in 
>>>>> 2.4 AFAIK. Obviously the version compiled on System B is linked against 
>>>>> version 2.5 of glibc.
>>>>>       
>>> Correct both have different thread  versions
>>>
>>>   
>>>>> You could check the outputs of your two glibc version to check for 
>>>>> differences ... (Just run them), the output should somewhat look like
>>>>>       
>>> this:
>>> yaa , correct  but  is there any compile option  in gcc that can ignore
>>> glibc versions or ABI changes ??
>>>
>>>  Is there any problem in "linux-gate.so.1" ??
>>>
>>> thank you 
>>> dinesh
>>>  
>>>   
>>
> 

Re: gcc compatibility

[Harald Krammer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

cdinesh schrieb:
> Properly
> Strike
> Protest
> 
>  Hi 
> 
>     I have two  Linux systems  have different gcc  version 
>           system A  -> gcc  (3.4.4)
>           system B  -> gcc  (4.1.2)
> 
> 
>   I would like to build test program that can be run on both systems 
>   ---------------------------
>   #include <stdio.h>
>   main(){
>    printf("hello world \n");
>   }
>   ---------------------------
>    gcc test.c -o test
> 
>   ldd on system A 
>          linux-gate.so.1 =>  (0x00d42000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x00b0c000)
>         /lib/ld-linux.so.2 (0x00af2000)
> 
>   ldd on system B 
>          linux-gate.so.1 =>  (0x00814000)
>         libc.so.6 => /lib/libc.so.6 (0x0054a000)
>         /lib/ld-linux.so.2 (0x0052d000)
> 
>    Test case 1 
>      Build test.c on system A and run on both systems A and B. 
>            on sytem A     ok
>             on system B    ok.
> 
>    Test case 2 
>      Build test.c on system B and run on both systems A and B. 
>              on system B   ok
>              on system A   error
>            error log 
>              # ./test
>               Floating point exception
> 
>              # ldd 
>              /usr/bin/ldd: line 124:  3911 Floating pointexception
> LD_TRACE_LOADED_OBJECTS=1 LD_WARN= 
>              LD_BIND_NOW= LD_LIBRARY_VERSION
>  =$verify_out LD_VERBOSE= "$@"
>  
>     for other information 
> 
>       System A 
>             kernel  2.6.12
>             gliibc version  2.3.6
>             binutils  2.15.92.0.2
>             selinux disable
> 
>       System B 
>             kernel  2.6.18
>             gliibc version  2.5
>             binutils  2.17.50.0.6
>             selinux disable
> 
> 
> I have a feeling the problem is in the libraries. Please give any advice ?
> 
> Thank you 
> 

Hello,
you can use a static link. (gcc -static test.c -o test).

It is a easy solution and often used, but keep in mind: A security
update (also bugfix) in glibc needs a recompilation of your application!

Nice greetings,
Harald

- --

Harald Krammer
Brucknerstrasse 33
A - 4020  Linz
AUSTRIA

Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIOxih9QlAsubHO9sRCDiBAKCMmR63int+hk3UxNTLADOn8s5vZgCfYsSC
HhvMzigRzKMbSjW03T9aq+U=
=03rc
-----END PGP SIGNATURE-----