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:
mabsh...@sage:/scratch/mabshoff/sage-3.4.alpha0/local/lib/python2.5/
config$ cd foo/
mabsh...@sage:/scratch/mabshoff/sage-3.4.alpha0/local/lib/python2.5/
config/foo$ ar xf ../libpython2.5.a
mabsh...@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
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
