On 10 March 2011 19:38, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > asyropoulos@xxxxxxx writes: > >> The 32bit was easy and works as it should. However, the 64bit does not >> compile and it stops with the following error message: >> >> ./perl -f -Ilib pod/buildtoc --build-toc -q >> Can't load 'lib/auto/re/re.so' for module re: ld.so.1: perl: fatal: >> relocation error: R_AMD64_PC32: >> file lib/auto/re/re.so: symbol main: value 0x28006b7dd34 does not fit >> at lib/XSLoader.pm line 70. >> >> I did a Google search and I had found out that this error message is >> produced when the compile >> tries to link position dependent code into a shared object. According >> to the GCC manual one needs >> to specify the -fPIC flag to ensure that position independent code is >> produced. In my case, the perl >> configuration script says that it will use this flag by default and it >> is used yet it does not help. Also, >> the -mimpure-text does not help when used when linking. So can anybody >> suggest a way to deal >> with this problem? Note that solstudio12.2 compiles perl with no >> problem, but there are a number >> of things that cannot be compiled with solstudio12.2. > > I think you have to talk to the perl developers. If the code is > compiled with -fPIC, and nothing else is affecting the code, this > particular error should not occur. So my first guess would be that > something else is affecting this, such as a version script or something > explicitly setting the symbol visibility. > > Ian There seems to be at least two things that can cause position dependent code to be created when the -fPIC option is used. * Assembly code * Use of of the GNU extension to C (I hate this ****ing extensions) that use "computed gotos" There's a description of how to trace the object file causing the problem at http://blogs.sun.com/rie/entry/my_relocations_don_t_fit Finding the bad library with non-PIC code is easy - just use: $ elfdump -d library | fgrep TEXTREL If a shared library shows any output from that command, then it has the problem. But it is no easy task to pinpoint the object file. If you understand it, please explain it to me, as I can't follow the description on that Sun blog. The Lisp interpreter ECL used to have this problem as it used computed gotos. That's been fixed in the latest ECL. I also know the statistics package R will not build on Solaris 64-bit due to the same problem. The R users guide just say to use the Sun compiler, and not gcc. I'd love to track down the reason gcc will not build R. I know its due to this issue, but finding what object file is causing the problem, then to find the source code, is no easy task. If you can use the Sun compiler rather than gcc, then it never seems to get this problem. Dave
