64-bit Solaris ports.
Dr. David Kirkby
x86 (fulvia on skynet) and OpenSolaris x64 (my own Sun Ultra 27).
It's too early to say Sage is stable on all 32-bit Solaris/OpenSolaris systems,
but I think it must be pretty close now.
That leaves the 64-bit ports to resolve. Sage builds 64-bit both on SPARC and
OpenSolaris, but its unstable on both - though on SPARC it is just about usable.
I've just tried building sage-4.5.3.alpha2.tar as 64-bit on 't2' and on my Sun
Ultra 27. It has already built on the Ultra 27, but fails to start, giving this
error.
====================================================================
ImportError: ld.so.1: python: fatal: relocation error: R_AMD64_PC32: file
/export/home/drkirkby/64/sage-4.5.3.alpha2/local/lib//libcliquer.so: symbol
main: value 0x281474cc7d4 does not fit
====================================================================
A Google brings up this very helpful page
http://blogs.sun.com/rie/entry/my_relocations_don_t_fit
which indicates the code for the library is probably not being compiled as PIC
code, so the compiler option -fPIC needs adding.
In fact, -fPIC is already there, which was bad news, as the fix was not quite as
easy as I thought.
But there's a useful command given in that web link.
$ elfdump -d somelibrary.so | fgrep TEXTREL
which gives no output for most shared libraries in Sage, but a few give an
output and so are potential problem libraries.
I wrote a little script, which checks all libraries.
drkirkby@hawk:~/64/sage-4.5.3.alpha2/local/lib$ cat find_bad_libraries
#!/bin/sh
for i in `ls *.so`
do
echo $i
elfdump -d $i | fgrep TEXTREL
done
When I run it on my OpenSolaris system, I find five bad 64-bit libraries - see
below.
These are
* libcliquer.so
* libecl.so
* libgroebner-0.6.4.so
* libpboriCudd-0.6.4.so
* libpolybori-0.6.4.so
When I last built Sage on 't2.math' in 64-bit, it did actually work, but was
*very* unstable. My guess is that looking at this libraries, to see if they have
any problems, would be well worth doing.
I managed to fix the libcliquer library in about 5 minutes. All that needed
changing was a whole host of gcc options to a very simple one.
I note on OpenSolaris, though ECL builds, Maxima will not install (see
http://trac.sagemath.org/sage_trac/ticket/9099) It was no great surprise to see
that there's a problem with the ECL library.
So I think
elfdump -d somelibrary.so | fgrep TEXTREL
should allow us to find any libraries which are perhaps mis-configured in 64-bit
mode.
drkirkby@hawk:~/64/sage-4.5.3.alpha2/local/lib$ ./find_bad_libraries
libatlas.so
libcblas.so
libcdd.so
libcddgmp.so
libcharset.so
libcliquer.so
[17] TEXTREL 0
[25] FLAGS 0x4 [ TEXTREL ]
libcord.so
libcsage.so
libcurvesntl.so
libecl.so
[24] TEXTREL 0
[32] FLAGS 0x4 [ TEXTREL ]
libf77blas.so
libflint.so
libfplll.so
libfreetype.so
libg0nntl.so
libgc.so
libgcrypt.so
libgd.so
libgivaro.so
libglpk.so
libgmp.so
libgmpxx.so
libgnutls-extra.so
libgnutls-openssl.so
libgnutls.so
libgpg-error.so
libgroebner-0.6.4.so
[25] TEXTREL 0
[33] FLAGS 0x4 [ TEXTREL ]
libgsl.so
libgslcblas.so
libhistory.so
libiconv.so
libiml.so
libjcntl.so
libLfunction.so
liblinbox.so
liblinboxsage.so
libm4ri-0.0.20100701.so
libm4ri.so
libmpfi.so
libmpfr.so
libmpir.so
libmpirxx.so
libntl-5.4.2.so
libntl.so
libopencdk.so
libpari.so
libpboriCudd-0.6.4.so
[25] TEXTREL 0
[33] FLAGS 0x4 [ TEXTREL ]
libpng12.so
libpolybori-0.6.4.so
[25] TEXTREL 0
[33] FLAGS 0x4 [ TEXTREL ]
libpynac.so
libpython2.6.so
librankntl.so
libreadline.so
libsingular.so
libsqlite3.so
libz.so
libzn_poly-0.9.so
libzn_poly.so
preloadable_libiconv.so
Jason Grout
> A Google brings up this very helpful page
>
> http://blogs.sun.com/rie/entry/my_relocations_don_t_fit
>
> which indicates the code for the library is probably not being compiled
> as PIC code, so the compiler option -fPIC needs adding.
>
> In fact, -fPIC is already there, which was bad news, as the fix was not
> quite as easy as I thought.
>
> But there's a useful command given in that web link.
>
> $ elfdump -d somelibrary.so | fgrep TEXTREL
>
> which gives no output for most shared libraries in Sage, but a few give
> an output and so are potential problem libraries.
For those wondering what TEXTREL is, but haven't read the webpage above,
here is the relevant section of the webpage:
---------------------
If you believe you have compiled all the components of your shared
object using -Kpic, and still see an error of this sort, look a little
more closely. First, determine if the link-editor thinks the shared
object contains text relocations.
$ elfdump -d library | fgrep TEXTREL
If this flag is found, then the link-editor thinks this file contains
non-pic code. One explanation might be that you have include an
assembler file in the shared library. Any assembler must be written
using position-independent instructions. Another explanation is that you
might have included objects from an archive library as part of the
link-edit. Typically, archives are built with non-pic objects.
-----------------------------
I would not be surprised if ECL contained assembly (maybe non-PIC?), for
example. If that's true, then it seems that fixing things would involve
more than just a compile-time switch, right?
Jason
Dr. David Kirkby
> If this flag is found, then the link-editor thinks this file contains
> non-pic code. One explanation might be that you have include an
> assembler file in the shared library. Any assembler must be written
> using position-independent instructions. Another explanation is that you
> might have included objects from an archive library as part of the
> link-edit. Typically, archives are built with non-pic objects.
>
> -----------------------------
>
> I would not be surprised if ECL contained assembly (maybe non-PIC?), for
> example. If that's true, then it seems that fixing things would involve
> more than just a compile-time switch, right?
>
> Jason
On Solaris x86, the assembly code for ECL has been disabled, using the option
--with-dffi=no - see #8089. So I don't think that's the issue.
Looking at
http://blogs.sun.com/rie/entry/my_relocations_don_t_fit
it does seem that's it possible to get the exact file where the problem lies,
with a bit of work.
In the case of libcliquer, the code was all compiled as -fPIC, but there was
some odd options. Just chaging the link line to
gcc -shared -o libcliquer.so object1.o object2.o .. etc
produced a library which the link editor is happy with. Whether the resulting
64-bit library actually works is another matter!!!
But I think some progress can be made.
Of the 5 libraries that the link editor is not happy with, two of them are
causing problems. So I guess the other three will probably too.
Dave
John H Palmieri
wrote:
[snip]
> When I run it on my OpenSolaris system, I find five bad 64-bit libraries - see
> below.
>
> These are
> * libcliquer.so
> * libecl.so
> * libgroebner-0.6.4.so
> * libpboriCudd-0.6.4.so
> * libpolybori-0.6.4.so
Solaris (either sparc or x86, either 32-bit or 64-bit), I see many
instances of this error message:
g++: unrecognized option '-KPIC'
Could that be related to the problem?
--
John
Dr. David Kirkby
It should not not be, though it could if -fPIC is not also used.
-KPIC is an option used for Sun's SunStudio compiler to generate position
independent code. -fPIC is an option used by GCC to generate position
independent code. So they are essentially equivalent
Only one should be given, and that should be the right one for the compiler.
However, unreconised options are ignored by both gcc and the Sun compiler, so
this is not necessarily a problem.
If we could find any cases where that warning is generated, but -fPIC is not
also used, that would be useful to know of.
Since 3 of the dubious files
all have 0.6.4 in the names, it rather suggests to me they are all part of the
same package (PolyBoRi), though the first one might possibly be something else,
though I doubt it.
Unfortunately, I know SCons is used when building PolyBori. If SCons is doing
something wrong, it is very difficult to change it (for me at least, and I know
the PolyBoRi developers struggle with it too). SCons tries to be too clever for
my liking. I noticed Minh gave up trying to fight with it, and converted cliquer
to a standard Makefile.
I think ECL will be easy to fix. If Juanjo, the ECL developer is made aware of a
problem, he will fix it. I'm very impressed with him.
With PolyBoRi, the problem might be more difficult, since SCons is involved in
the build, but the PolyBoRi developers are helpful.
These issues could potentially affect all platforms - not just Solaris.
I first thing I will do is to download the latest ECL and see if the problem has
been fixed. If not, I'll report this to the ECL list.
Dave