#10508: Update ATLAS to stable version 3.10
-----------------------------------------------------------------------------------------+
Reporter: vbraun
| Owner: tbd
Type: enhancement
| Status: needs_work
Priority: major
| Milestone: sage-5.8
Component: packages
| Resolution:
Keywords: ATLAS
| Work issues:
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
| Merged in:
Dependencies: #13160, #13395, #13392, #13416, #12994, #9906, #12883,
#13123, #13415 | Stopgaps:
-----------------------------------------------------------------------------------------+
Comment (by leif):
Replying to [comment:338 jpflori]:
> Replying to [comment:337 jpflori]:
> > Replying to [comment:178 kcrisman]:
> > > Like I said, don't count those chickens. I think this is pretty
clearly related, given the libatlas reference.
> > > {{{
> > > building package 'graphics'
> > > mkdir ../../../library/graphics
> > > mkdir ../../../library/graphics/R
> > > mkdir ../../../library/graphics/po
> > > byte-compiling package 'graphics'
> > > Error in dyn.load(file, DLLpath = DLLpath, ...) :
> > > unable to load shared object
'/Users/student/Desktop/sage-5.3.rc0/spkg/build/r-2.14.0.p3/src/library/grDevices/libs/grDevices.so':
> > >
dlopen(/Users/student/Desktop/sage-5.3.rc0/spkg/build/r-2.14.0.p3/src/library/grDevices/libs/grDevices.so,
6): Symbol not found: _ATL_DecAtomicCount
> > > Referenced from:
/Users/student/Desktop/sage-5.3.rc0/local/lib/libatlas.2.dylib
> > > Expected in: dynamic lookup
> > > Calls: <Anonymous> ... namespaceImport -> loadNamespace ->
library.dynam -> dyn.load
> > > Execution halted
> > > make[6]: *** [../../../library/graphics/R/graphics.rdb] Error 1
> > > make[5]: *** [all] Error 2
> > > make[4]: *** [R] Error 1
> > > make[3]: *** [R] Error 1
> > > make[2]: *** [R] Error 1
> > > Error building R.
> > >
> > > real 44m11.283s
> > > user 28m7.249s
> > > sys 6m59.266s
> > >
************************************************************************
> > > Error installing package r-2.14.0.p3
> > >
************************************************************************
> > > }}}
> > > I think that's the last spkg other than rubiks and sagetex,
actually, so cvxopt and r might be the only problems with this approach.
> > I get similar problems on sparc hardware.
> > There must be something wrong in the build system because some asm
routines are not available for sparc and it does not fallback to generic
routines but rather leaves undefined symbol for DecAtomicCount (and two
other related functions).
> >
> > By the way these functions seem thread related but passing again -t 0
to configure as used to be the case in our previous spkg does not solve
the problem, the thread part still gets built, even if it may be not used.
>
> From what I've seen on a Debian ppc64, by default the correct mut
implementation of DecAtomicCount and the two other functions get picked up
(note there is a ppc assembly implem but its commented as unstable and an
#error statement is put in the assembly file).
>
> But if I put back the "-t 0" param when configuring ATLAS, then these
three functions do not get defined, which would be ok if other thread
related functions which point to these functions were not defined...
> So if I explicitely disable thread, ATLAS still builds some (but not
all!) of the thread related functions and if I tried to dlopen the library
the runtime linker fails with undefined symbols as reported by Karl
Dieter.
Well, this '''might''' be due to how ''Sage'' builds shared libraries from
ATLAS' ''static'' ones, as statically linking by default does some kind of
dead code elimination ("removing" unused modules and hence potentially
dead references).
[[BR]]
> Nonetheless I don't think that the problem I just stated is what Karl
Dieter encountered as he used the default configuration and so should get
the fallback implementaiton of DecAtomicCount and related.
> I also encountered such a behavior on sparc where there is no assembly
routines and somehow the fallback implementation is not picked as well.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10508#comment:339>
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.
