#9508: Fix all ATLAS build problems on Solaris/OpenSolaris
----------------------------+-----------------------------------------------
Reporter: drkirkby | Owner: drkirkby
Type: defect | Status: new
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:7 jhpalmieri]:
> Is this ready for review?
No. I think I found an issue on SPARC. I want to make double sure this is
OK. My 32-bit SPARC build did not work properly.
> Regarding the check {{{"x`uname -m`" = xi86pc}}}, does this guarantee
Solaris or !OpenSolaris somehow?
No, it guarantees the hardware is x86 based. That includes the 64-bit
hardware. You will get the same on both !OpenSolaris and Solaris. Note
!OpenSolaris does run on SPARC hardware too, though that is not very
common. I don't have any !OpenSolaris SPARC systems running myself and I'm
not aware of anywhere where there is one.
> I can't find a definitive description of the output of "uname -m",
although I've seen a few places (including the uname man page on Solaris)
suggest that you should use "uname -p" instead of "uname -m"...
I have never noticed that in the uname man page. My preference for -m, and
not -p, is that -m is defined by POSIX standards:
http://www.opengroup.org/onlinepubs/009695399/utilities/uname.html
but there is no requirement for uname to support the -p option. That
causes a problem on systems like HP-UX, where there is no -p option. So
before using uname -p, one should test that the system supports the
option. I guess since this is in a Solaris specific part of the file, we
could use uname -p, but I'm not over keen on using non-portable options if
portable ones exist.
I can't believe Sun could ever possibly remove the -m option, as Solaris
would then not be a POSIX compliant operating system - it would drop to be
a "Unix-like" operating system, as is Linux. I must admit I am puzzled why
they recommend you use a non-portable option in preference to a portable
one.
> Would it be better (or at least easier to read) to use {{{uname}}}
instead of {{{uname -m}}}?
No, since {{{spkg-install-script}}} does need to know the processor type.
Trying to make those substitutions on a SPARC processor would make no
sense. However, I can certainly clarify things a bit more with comments,
similar to what I have put above.
> Anyway, this is a minor point. The changes look good and I'm building
this on several machines to test it out. I think if this gets a positive
review, then we can close #9356: with this new spkg, ATLAS builds all of
the appropriate libraries on Solaris, so we don't need to modify how
SAGE_ATLAS_LIB works.
Let me know how your build goes. My 32-bit SPARC build did not work, so
I'd be interested in how you get on with 32-bit builds on SPARC.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9508#comment:8>
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.
