Samson Luk <samsonluk@xxxxxxxxx> writes: > 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. When loading the shared library, there is an undefined symbol. That is the problem you need to fix. > attempt load re.so manually: > $ lib/auto/re/re.so > Segmentation fault You can't normally run shared libraries from the shell. Shared libraries are not executables. (It's possible to design your shared library so that it can be run from the shell, but that is unusual.) > 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? You are running perl, so you are using the dynamic linker which perl is using. If you want to change the dynamic linker, you need to change it in the perl executable. But it seems to me that your problem is an undefined symbol, and has nothing to do with the dynamic linker. Ian
