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.
