Shared python library or fPIC issue on AMD64

[Pat LeSmithe]

Hello,

In building the experimental ParaView package,

http://trac.sagemath.org/sage_trac/ticket/5279 ,

on a x86_64 Fedora 9 machine with the corresponding binary distribution
of Sage 3.2.3, I got this error:

/usr/bin/ld:
/home/qed777/apps/sage/sage-3.2.3-Fedora_release_9-x86_64-Linux/local/lib/python2.5/config/libpython2.5.a(abstract.o):
relocation R_X86_64_32 against `a local symbol' can not be used when
making a shared object; recompile with -fPIC
/home/qed777/apps/sage/sage-3.2.3-Fedora_release_9-x86_64-Linux/local/lib/python2.5/config/libpython2.5.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [bin/libvtkPVPythonInterpretor.so] Error 1
make[1]: ***
[Utilities/VTKPythonWrapping/Executable/CMakeFiles/vtkPVPythonInterpretor.dir/all]
Error 2
make: *** [all] Error 2
Error building ParaView .

Subsequent attempts end with the same error but occasionally when
linking one of ParaView's other Python-related shared libraries. (The
latter behavior may stem from "make -j 2", but I'm not sure.)

This seems to be an example of a known AMD64 quirk:

http://mail.python.org/pipermail/python-bugs-list/2006-October/035809.html .

Is this happening because the Sage distribution includes libpython2.5.a
but not lipython2.5.so? Or is it because some flags, such as "-fPIC,"
were [intentionally] omitted when building the static library? (If it
matters, I've already added "-fPIC" to the Paraview build flags.)
Either way, can/should I reconfigure the build to link to the system's
(i.e., not Sage's) Python library?

Also, although I haven't built the experimental VTK spkg, this seems to
suggest I'd have a similar problem with it. I've previously built the
same versions of VTK and ParaView outside of Sage without incident.
Interestingly, Kitware's binary installation of ParaView includes both
libpython2.5.a and libpython2.5-pic.a, as well as a broken link to a
missing libpython2.5.so, but it runs fine.

Thanks!

Sincerely,
Pat LeSmithe

[Jaap Spies]

Pat LeSmithe wrote:
>
> Hello,
>
> In building the experimental ParaView package,
>
> http://trac.sagemath.org/sage_trac/ticket/5279 ,
>
> on a x86_64 Fedora 9 machine with the corresponding binary distribution
> of Sage 3.2.3, I got this error:
>
> /usr/bin/ld:
> /home/qed777/apps/sage/sage-3.2.3-Fedora_release_9-x86_64-Linux/local/lib/python2.5/config/libpython2.5.a(abstract.o):
> relocation R_X86_64_32 against `a local symbol' can not be used when
> making a shared object; recompile with -fPIC
> /home/qed777/apps/sage/sage-3.2.3-Fedora_release_9-x86_64-Linux/local/lib/python2.5/config/libpython2.5.a:
> could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[2]: *** [bin/libvtkPVPythonInterpretor.so] Error 1
> make[1]: ***
> [Utilities/VTKPythonWrapping/Executable/CMakeFiles/vtkPVPythonInterpretor.dir/all]
> Error 2
> make: *** [all] Error 2
> Error building ParaView .
>

I've seen this when I tried to build paraview on sage.math. I'm sorry but
I don't have an other 64k machine to test this.

> Subsequent attempts end with the same error but occasionally when
> linking one of ParaView's other Python-related shared libraries. (The
> latter behavior may stem from "make -j 2", but I'm not sure.)
>
> This seems to be an example of a known AMD64 quirk:
>
> http://mail.python.org/pipermail/python-bugs-list/2006-October/035809.html .
>
> Is this happening because the Sage distribution includes libpython2.5.a
> but not lipython2.5.so? Or is it because some flags, such as "-fPIC,"
> were [intentionally] omitted when building the static library? (If it
> matters, I've already added "-fPIC" to the Paraview build flags.)
> Either way, can/should I reconfigure the build to link to the system's
> (i.e., not Sage's) Python library?
>

This will not work I think.

> Also, although I haven't built the experimental VTK spkg, this seems to
> suggest I'd have a similar problem with it.

The experimental vtk-5.2.1.spkg builds on sage.math ubuntu-8.04 64k.

I've previously built the
> same versions of VTK and ParaView outside of Sage without incident.
> Interestingly, Kitware's binary installation of ParaView includes both
> libpython2.5.a and libpython2.5-pic.a, as well as a broken link to a
> missing libpython2.5.so, but it runs fine.
>

Can you try to configure manually with ccmake and see what happens?

Jaap

[mabshoff]

On Mar 1, 8:46 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
> Pat LeSmithe wrote:

<SNIP>

Hi,

> > /usr/bin/ld:
> > /home/qed777/apps/sage/sage-3.2.3-Fedora_release_9-x86_64-Linux/local/lib/p ython2.5/config/libpython2.5.a(abstract.o):

> > relocation R_X86_64_32 against `a local symbol' can not be used when
> > making a shared object; recompile with -fPIC
> > /home/qed777/apps/sage/sage-3.2.3-Fedora_release_9-x86_64-Linux/local/lib/p ython2.5/config/libpython2.5.a:
> > could not read symbols: Bad value
> > collect2: ld returned 1 exit status
> > make[2]: *** [bin/libvtkPVPythonInterpretor.so] Error 1
> > make[1]: ***
> > [Utilities/VTKPythonWrapping/Executable/CMakeFiles/vtkPVPythonInterpretor.d ir/all]
> > Error 2
> > make: *** [all] Error 2
> > Error building ParaView .
>
> I've seen this when I tried to build paraview on sage.math. I'm sorry but
> I don't have an other 64k machine to test this.

This is ld dependent, i.e. recent binutils require -fPIC. This is also
arch dependent, i.e. it is required on x86-64, but older versions of
binutils produce PIC code per default for some distributions.

> > Subsequent attempts end with the same error but occasionally when
> > linking one of ParaView's other Python-related shared libraries.  (The
> > latter behavior may stem from "make -j 2", but I'm not sure.)
>
> > This seems to be an example of a known AMD64 quirk:
>

> >http://mail.python.org/pipermail/python-bugs-list/2006-October/035809....

It is a general problem. The issue is that -fPIC code is slower than
code that hasn't been compiled without PIC :)

> > Is this happening because the Sage distribution includes libpython2.5.a
> > but not lipython2.5.so?  Or is it because some flags, such as "-fPIC,"
> > were [intentionally] omitted when building the static library?  (If it
> > matters, I've already added "-fPIC" to the Paraview build flags.)
> > Either way, can/should I reconfigure the build to link to the system's
> > (i.e., not Sage's) Python library?
>
> This will not work I think.

It would, but do the following: take a throw away Python tree and
modify the python.spkg to add -fPIC to the default flags. Take the
libpython2.5.a and turn it into a shared library:

mabshoff@sage:/scratch/mabshoff/sage-3.4.alpha0/local/lib/python2.5/
config$ cd foo/
mabshoff@sage:/scratch/mabshoff/sage-3.4.alpha0/local/lib/python2.5/
config/foo$ ar xf ../libpython2.5.a
mabshoff@sage:/scratch/mabshoff/sage-3.4.alpha0/local/lib/python2.5/
config/foo$ gcc -shared *.o -o libpython.so
/usr/bin/ld: abstract.o: relocation R_X86_64_32 against `a local

symbol' can not be used when making a shared object; recompile with -
fPIC

abstract.o: could not read symbols: Bad value

collect2: ld returned 1 exit status

This blows up because I was too lazy to build a libpython2.5.a with -
fPIC, but the rest should work. Then drop that libpython.so into
$SAGE_LOCAL/lib and the linker should pick it up.

> > Also, although I haven't built the experimental VTK spkg, this seems to
> > suggest I'd have a similar problem with it.
>
> The experimental vtk-5.2.1.spkg builds on sage.math ubuntu-8.04 64k.
>
>    I've previously built the
>
> > same versions of VTK and ParaView outside of Sage without incident.
> > Interestingly, Kitware's binary installation of ParaView includes both
> > libpython2.5.a and libpython2.5-pic.a, as well as a broken link to a
> > missing libpython2.5.so, but it runs fine.
>
> Can you try to configure manually with ccmake and see what happens?

I am surprised python doesn't offer a PIC static lib, but it might be
available in Python 2.6.

> Jaap

Cheers,

Michael

[Tim Spriggs]

I recently ran into an error I thought was -fPIC related (similar
errors) but the libs and the program I was compiling were all compiled
with -fPIC. Turns out gcc -G was causing problems and changing to gcc -
shared fixed the issue. The exact same build process worked on solaris-
i386 and the issue was found while compiling for solaris-amd64.

Perhaps it is completely unrelated but I thought I would mention it.

Cheers,
-Tim

[Pat LeSmithe]

Hello,

Many thanks to all for their advice. Converting to a shared library
seems to have worked. After extracting members from a PIC'd
libpython2.5.a, I did

gcc -shared *.o -o libpython.so -lm -lpthread -lutil -ldl ,

copied the .so to $SAGE_LOCAL/lib, and changed spkg-install accordingly:

-DPYTHON_LIBRARY:FILEPATH=$SAGE_LOCAL/lib/libpython.so\ .

Then the only problem is that Sage's libreadline.so isn't linked to a
libtermcap.so, as it is with Fedora 9. I'm not sure where to add Sage's
libtermcap.a in the CMake directives, so I've converted again:

ar xf libtermcap.a
gcc -shared *.o -o libtermcap.so ,

etc. Finally, since the CMAKE_BUILD_TYPE is unset, I've added

-DCMAKE_EXE_LINKER_FLAGS:STRING=-ltermcap\

to spkg-install. There's probably a better way. I don't know how much
difference -O3 makes, but it might be useful to set the build type to
RELEASE (and move -ltermcap) or to add optimization flags to CMAKE_*_FLAGS.

On a somewhat related note, and if it's not already happening, how about
a "continuous" build testing server for Sage? One example:

http://www.cdash.org/
http://public.kitware.com/dashboard.php

On an unrelated note, there's an interesting recent Google Tech Talk on
JavaScript and its various parts:

http://www.youtube.com/watch?v=hQVTIJBZook

I'm not really a developer, but I found it enlightening.

And if you're still reading, here's a fake quote:

"There can be no greater praise for Sage than that
students and scientists alike curse at it as vehemently
as they did at Maple, Mathematica, Matlab,..."
- Dr. I. M. DeSage, future Rings Medal winner

That's a [lame] joke. Sorry. Thanks again.

Sincerely,
Pat LeSmithe

[Jaap Spies]

mabshoff wrote:
>
>
> On Mar 1, 8:46 am, Jaap Spies <j.sp...@hccnet.nl> wrote:
>> Pat LeSmithe wrote:
>
> <SNIP>

[...]

> It would, but do the following: take a throw away Python tree and
> modify the python.spkg to add -fPIC to the default flags. Take the
> libpython2.5.a and turn it into a shared library:
>
> mabshoff@sage:/scratch/mabshoff/sage-3.4.alpha0/local/lib/python2.5/
> config$ cd foo/
> mabshoff@sage:/scratch/mabshoff/sage-3.4.alpha0/local/lib/python2.5/
> config/foo$ ar xf ../libpython2.5.a
> mabshoff@sage:/scratch/mabshoff/sage-3.4.alpha0/local/lib/python2.5/
> config/foo$ gcc -shared *.o -o libpython.so
> /usr/bin/ld: abstract.o: relocation R_X86_64_32 against `a local
> symbol' can not be used when making a shared object; recompile with -
> fPIC
> abstract.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
>
> This blows up because I was too lazy to build a libpython2.5.a with -
> fPIC, but the rest should work. Then drop that libpython.so into
> $SAGE_LOCAL/lib and the linker should pick it up.

This procedure will not save my experimental paraview spkg :(!

Jaap