#17630: Further clean up of ATLAS (or equivalent BLAS) linking
-------------------------------------+-------------------------------------
Reporter: jpflori | Owner:
Type: defect | Status: needs_work
Priority: major | Milestone: sage-6.5
Component: packages: | Resolution:
standard | Merged in:
Keywords: | Reviewers:
Authors: Jean-Pierre | Work issues:
Flori, François Bissey | Commit:
Report Upstream: N/A | 764c3b574a438ef36b3a8a29552a7691514a37fb
Branch: u/fbissey/blas | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by fbissey):
When I started talking about #17075 and associated work to be able to use
any `blas/lapack` our goal was to use `pkgconfig` and
`https://github.com/matze/pkgconfig` as a python interface to it. This is
what `sage-on-gentoo` is currently using. The fact that the python
interface was also standard escaped me.
We included `pkgconfig` in sage when we upgraded to `matplotlib-1.3.x`
after I determined that it was the only to build it on OS X while
reviewing that ticket. That would have been after #17075 but I am not sure
if it was before this ticket.
For reference this is the current sage-on-gentoo patch for 6.8.beta6
https://github.com/cschwan/sage-on-gentoo/blob/master/sci-
mathematics/sage/files/sage-6.8-blas-r1.patch
The librarydir part is for dealing with BLAS/LAPACK installed in less
standard location (`/opt`) where they may be out of the library search
path when linking. It still relies on said path to be in `ld.so.config` or
equivalent. Typical cases are intel MKL and AMD acml. The ability to
compile against MKL is one of the key motivation here.
Since we have all the elements, going `.pc` all the way is fine. I'll
rewrite the whole thing.
As mentioned before I spent some time working on OS X and that's also one
of my motivation to rewrite some stuff. That's an interesting little story
that touch `sage-env` (surprise)....
So Jean-Pierre put this in `numpy` and `scipy`
{{{
if [ -n "${LDFLAGS+set}" ]; then
if [ "$UNAME" != "Darwin" ]; then
export LDFLAGS="-bundle -undefined dynamic_lookup $LDFLAGS"
export CPPFLAGS="-D__ACCELERATE__ $CPPFLAGS"
else
export LDFLAGS="-shared $LDFLAGS"
fi
fi
}}}
Which definitely looked wrong on first glance but I trusted Jean-Pierre.
Well it is wrong and compilation will fail on OS X because somehow you'll
`-bundle` and `-shared` in `LDFLAGS` at the same time. Unless you include
Jean-Pierre changes to `sage-env` in which case `numpy` at least compile.
I'll hazard that the change to `sage-env` enable compilation under linux
as well somehow.
So there we are the change to `sage-env` was allowing wrong stuff in
`numpy` and `scipy` (not on OS X) to work to some extent.
My local branch is in a bit of a mess and I think I pushed too much stuff
on trac so I'll get a clean branch in.
--
Ticket URL: <http://trac.sagemath.org/ticket/17630#comment:94>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
