* gcc compatibility @ 2008-05-22 3:38 cdinesh 2008-05-22 5:09 ` Sven Eschenberg 2008-05-27 9:09 ` Harald Krammer 0 siblings, 2 replies; 7+ messages in thread From: cdinesh @ 2008-05-22 3:38 UTC (permalink / raw) To: gcc-help 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gcc compatibility 2008-05-22 3:38 gcc compatibility cdinesh @ 2008-05-22 5:09 ` Sven Eschenberg 2008-05-22 7:18 ` cdinesh 2008-05-27 9:09 ` Harald Krammer 1 sibling, 1 reply; 7+ messages in thread From: Sven Eschenberg @ 2008-05-22 5:09 UTC (permalink / raw) To: cdinesh; +Cc: gcc-help 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 > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gcc compatibility 2008-05-22 5:09 ` Sven Eschenberg @ 2008-05-22 7:18 ` cdinesh 2008-05-22 8:17 ` Sven Eschenberg 0 siblings, 1 reply; 7+ messages in thread From: cdinesh @ 2008-05-22 7:18 UTC (permalink / raw) To: gcc-help 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gcc compatibility 2008-05-22 7:18 ` cdinesh @ 2008-05-22 8:17 ` Sven Eschenberg 2008-05-23 10:01 ` cdinesh 0 siblings, 1 reply; 7+ messages in thread From: Sven Eschenberg @ 2008-05-22 8:17 UTC (permalink / raw) To: cdinesh; +Cc: gcc-help 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 > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gcc compatibility 2008-05-22 8:17 ` Sven Eschenberg @ 2008-05-23 10:01 ` cdinesh 2008-05-23 15:18 ` Kai Ruottu 0 siblings, 1 reply; 7+ messages in thread From: cdinesh @ 2008-05-23 10:01 UTC (permalink / raw) To: gcc-help 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gcc compatibility 2008-05-23 10:01 ` cdinesh @ 2008-05-23 15:18 ` Kai Ruottu 0 siblings, 0 replies; 7+ messages in thread From: Kai Ruottu @ 2008-05-23 15:18 UTC (permalink / raw) To: cdinesh; +Cc: gcc-help 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 >>> >>> >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gcc compatibility 2008-05-22 3:38 gcc compatibility cdinesh 2008-05-22 5:09 ` Sven Eschenberg @ 2008-05-27 9:09 ` Harald Krammer 1 sibling, 0 replies; 7+ messages in thread From: Harald Krammer @ 2008-05-27 9:09 UTC (permalink / raw) To: cdinesh; +Cc: gcc-help -----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----- ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-05-26 20:08 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-05-22 3:38 gcc compatibility cdinesh 2008-05-22 5:09 ` Sven Eschenberg 2008-05-22 7:18 ` cdinesh 2008-05-22 8:17 ` Sven Eschenberg 2008-05-23 10:01 ` cdinesh 2008-05-23 15:18 ` Kai Ruottu 2008-05-27 9:09 ` Harald Krammer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).