#10508: Update ATLAS to stable version 3.10.1
---------------------------------------------------------------------------------------------------------+
Reporter: vbraun
| Owner: tbd
Type: enhancement
| Status: needs_work
Priority: major
| Milestone: sage-5.10
Component: packages: standard
| Resolution:
Keywords: ATLAS spkg
| Work issues: linker errors
Report Upstream: Reported upstream. No feedback yet.
| Reviewers: Benjamin Jones, Karl-Dieter Crisman,
Dmitrii Pasechnik, Georg Weber, François Bissey, John Palmieri
Authors: Volker Braun, Jeroen Demeyer, Jean-Pierre Flori
| Merged in:
Dependencies: #13160, #13395, #13392, #13416, #12994, #9906, #12883,
#13123, #13415, #14344, #14465 | Stopgaps:
---------------------------------------------------------------------------------------------------------+
Comment (by jpflori):
Replying to [comment:446 leif]:
> Replying to [comment:445 jpflori]:
> > I got why this is failing:
> > basically it seems that atlas builds the thread stuff using an
assembly version and a mutex version suffixed with _mut, put everything in
the static libatlas.a, and then tests if the assembly version is actually
faster.
> > Usually it is and every thing is fine, but if not, then it rebuilds
the mutex versions without the mut suffix and adds it to the static
libatlas.a.
> > So when we turn it into a shared library the linker fails because
these symbols are available in two different objects we extracted from the
static archive.
> >
> > Now the solution is to modify ATLAS build system which is non-trivial
without upstream support but might be feasible, I'll have a look.
>
> Or just build the shared library from the static one properly ;-), i.e.,
don't add both (or three?) "versions" of object files to the shared
library if they define the same function(s)...
>
I don't see a really easy way to do that in full generality.
I don't even know what will happen (of course I know what should happen)
when linking to the static library, which object file will be picked up to
resolve the function call?
Volker's solution is not the right way to go but at least it will easily
workaround the problem.
> [[BR]]
>
> > At first I wonder why the static archive produced for tuning is just
modified (running "ar r") in the "build" phase, and not wiped out and then
rebuilt from scratch.
>
> Presumably because that's faster. (There are 3200+ object files in the
archive.)
Good point.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10508#comment:451>
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
