#3256: [with patch; mixed review] soname and correct -fPIC handling for zn_poly
---------------------------+------------------------------------------------
Reporter: tabbott | Owner: mabshoff
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.3.1
Component: packages | Keywords: editor_mabshoff
Work_issues: | Author:
Upstream: N/A | Reviewer:
Merged: |
---------------------------+------------------------------------------------
Comment(by drkirkby):
I believe what we need to do is to make better use of sage-env.
Virtually every package has something like
{{{
if [ `uname` = "Darwin" -a "$SAGE64" = "yes" ]; then
CFLAGS = "$CFLAGS -m64"
fi
}}}
Lets consider what are 3 major things wrong with this.
* 64-bit builds are possible on other platforms like Solaris, which is a
supported operating system. So SAGE64 should not be restricted to Darwin.
* -m64 works for the GNU compiler and Sun compilers, but other options
are used to generate 64-bit code on other platforms.
* The same code is written in loads of packages, adding clutter.
It would be far more sensible to set the CFLAGS once, taking into account
the compiler, platform, setting of SAGE64 and other variables.
I'd suggest that we replace all this different library names (.dll on
Cygwin, .so on most platforms, .dlyn on some, .sl on HP-UX), with a simple
$SHARED_LIBRARY_EXTENSION. Then set that once and for all, and people
don't have to worry about it, just refer to it as a variable.
#6595 shows two examples of what William considers serious bugs, which
were only found when the Sun compiler was used. In one case, a function
computed an answer, but never returned it to what called it. g++ accepted
that. The Sun compiler will not. There's a lot more to be gained by
writing portable code than simply getting code to run on other systems.
#7505 will allow the compiler to be determined easily, whether that be
gcc, Sun Studio, HP's on HP-UX, IBM's on AIX, and several others. Once we
know what compiler we have, we have a reasonable chance of knowing the
right options.
Anyway, there is a lot we can do to improve things, but I do agree that
doing a lot of things in spkg-install is not sensible. It would seem
sensible that only has things specific to that package, rather than code
which needs to be in every package.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/3256#comment:12>
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.
