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
