#9508: Fix all ATLAS build problems on Solaris/OpenSolaris
----------------------------+-----------------------------------------------
Reporter: drkirkby | Owner: drkirkby
Type: defect | Status: needs_info
Priority: major | Milestone: sage-4.5.3
Component: solaris | Keywords:
Author: David Kirkby | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
----------------------------+-----------------------------------------------
Comment(by drkirkby):
Replying to [comment:14 jhpalmieri]:
> On fulvia, 32-bit build, the old version of ATLAS fails to build, but
this one succeeds. With the new one, I have the same situation as with
mark: R fails to build '''unless I delete liblapack.so'''. Then it
succeeds.
We will at some point need to run the R test suite, as there are reports
in the R manual that R fails some tests if built with gcc. It's also
reported R can't be built on Solaris 64-bit without the Sun compilers.
The Sage doctests don't really test R. But once we can get a Sage release
that builds on fulvia without various hacks, it will be much easier to
test. SAGE_CHECK can then be used to test R properly.
> Right now the Sage library is building; I'm curious about how many
doctest failures I'll see.
Thank you John.
It would be nice to understand the problem, but if all else fails, a bit
of code that deletes {{{liblapack.so}}} on Solaris is trivial.
I'd like to know if Linbox or ATLAS is at fault with Linbox believing the
ATLAS library is 32-bit when building 64-bit. ATLAS is clearly not 32-bit,
since if you extract the objects with {{{ar -x foobar.a}}} all the object
files are 64-bit. But perhaps there is something one needs to code into a
static library to make it easier for software to realise the objects are
64-bit. I'll ask on comp.unix.solaris about this.
It is remotely possible that copying the 64-bit library to
{{{$SAGE_LOCAL/lib/amd64}}} or {{{$SAGE_LOCAL/lib/sparcv9}}} will make
Linbox look for the library. On Solaris, all 64-bit libraries should be in
a {{{lib/amd64}}} or {{{lib/sparcv9}}} directory. That allows both 32-bit
and 64-bit libraries to be on the same system. If you use the {{{file}}}
command on the libraries in {{{/usr/lib}}}, you will see they are all
32-bit. In {{{/usr/lib/amd64}}} on x86 systems, or {{{/usr/lib/sparcv9}}}
on SPARC system, you will see they are 64-bit. That might be a way of
getting Linbox to behave. It might also be a way of getting R to behave,
though I don't think the R problem is a 32-bit vs 64-bit issues, whereas
the Linobx problem is.
> For the record, I built on fulvia using Sage 4.5.2.rc1 + this ATLAS spkg
+ the singular 3-1-1-4 spkg from #8059. Once the Sage library builds
(assuming it builds successfully), I'll apply the Sage library patch from
#8059 also.
Great. These systems seem to be coming together now. Most of the fixes for
one variant of Solaris apply to the others too. I thought the Cygwin port
would be completed before the other Solaris ports, but now I'm not so
sure. I think its quite possible we could have Sage running 32-bit and
64-bit on both SPARC and x86 in the not too distant future.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9508#comment:15>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
