#7761: Python 2.6.2.p4 faills to build on OpenSolaris
----------------------------------------------------------+-----------------
Reporter: drkirkby | Owner:
drkirkby
Type: defect | Status:
needs_work
Priority: major | Milestone:
sage-4.3.1
Component: solaris | Resolution:
fixed
Keywords: python open solaris | Author:
David Kirkby
Upstream: None of the above - read trac for reasoning. | Reviewer:
Jaap Spies
Merged: | Work_issues:
----------------------------------------------------------+-----------------
Changes (by drkirkby):
* merged: sage-4.3.1.alpha2 =>
Comment:
I can understand why this was not merged. I'm just in the process of
updating #7818. I just need to double check everything. But the main
change is that
* The user can supply SAGE_CFLAGS to set some CFLAGS they want. Since
they are not setting CFLAGS, them doing so will not risk corrupting the
Sage environment.
* CFLAGS will not be exported, but instead 'SAGE_COMMON_CFLAGS', which
will contain what the user specific in SAGE_CFLAGS, plus those flags I
deem sensible.
* Any spkg-install script that wants to use these flags, would have to do
so by explicitly doing so via.
CFLAGS="$SAGE_COMOON_CFLAGS"
That I believe will be safe. No package is forced to use my flags, but
they can choose to. Hence I believe the changes to sage-env will be 100%
safe, as they will not change any commonly used environment variables.
So that's what I intend to do with sage-env. Now to the specific of this
package.
Prior to writing this new package, I looked at Python's spkg-install to
see how the 64-bit build has been enabled on OS X, and you can see it
added -m64 to gcc, so "gcc -m64" was used as a compiler. Hence I basically
used a similar method.
Having later looked more carefully at the python documentation, the way to
pass flags is not the way it is done on the spkg-install for OS X, so
whist it may work, it is not the right way to do it.
I think the best solution is that I update sage-env, then update the
python package, but in a way that is specific to Solaris, AIX and HP-UX.
Then at a later date, we can try in an alpha0 to drop it in without it
being specific to that platform.
I think the ability to allow the user to pass their own flags is quite
important, as they can use that to optimise gcc for thier processor. At
the momemnt, 95% of Sage's code is being built for a generic processor,
and not exploiting the features of anyones particular processor.
So let me update sage-env in a safe way, then update this, to make use of
sage-env's changes, but only on some rarer platforms.
I think in the short term, Jaap should not worry about setting CFLAGS
globally if it allows a package to build. Progress can then be made. He
can always break the build process manually at some point, and unset it,
just before cython gets to work.
Leave it with me. I'll make what I believe are sensible decisions, then
others can comment of course. In the mean time, I'm happy with this not
being merged just now. I do agree it is sub-optimal.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7761#comment:18>
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.
