Thanks Ian... the reason I asked because I have encountered problems
when I have an alternative sysroot to compile perl, the compilation
break at the following:
./perl -f -Ilib pod/buildtoc --build-toc -q
Can't load 'lib/auto/re/re.so' for module re: lib/auto/re/re.so:
undefined symbol: PL_utf8_X_extend at lib/XSLoader.pm line 70.
at lib/re.pm line 69
Compilation failed in require at lib/Text/Wrap.pm line 50.
It complaint Can't load 'lib/auto/re/re.so' and take a look on re.so:
$ ldd lib/auto/re/re.so
libgcc_s.so.1 => /usr/lib/cs2010q1/lib/libgcc_s.so.1 (0x40050000)
libc.so.6 => /usr/lib/cs2010q1/lib/libc.so.6 (0x40063000)
/lib/ld-linux.so.3 (0x2a000000)
attempt load re.so manually:
$ lib/auto/re/re.so
Segmentation fault
re.so is not able to load when I cannot specify a correct
ld-linux.so.3 in my alternate sys-root which is
/usr/lib/cs2010q1/lib/ld-linux.so.3 instead of the system default
/lib/ld-linux.so.3
Any idea how to overcome this hurdle if gcc unable to specify a
dynamic linker in a shared object?
Regards,
Samson
On Thu, Oct 14, 2010 at 11:50 AM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
> It does not make sense to set the dynamic linker for a shared library,
> because that shared library has to be loaded by something, and in
> particular it has to be loaded by some dynamic linker. ÂIn other words,
> by the time the shared library is loaded, the dynamic linker is already
> running. ÂThere is no point to storing a dynamic linker in a shared
> library, because it will never be used.
>
> Ian
>
