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
Tim Spriggs wrote:
> 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
>
> On Mar 1, 12:00 pm, mabshoff <mabsh...@googlemail.com> wrote:
>> 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
-~----------~----~----~----~------~----~------~--~---
