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
