Opened 11 years ago
Last modified 9 years ago
#10508 closed enhancement
Update ATLAS to stable version 3.10 — at Version 241
Reported by:  vbraun  Owned by:  tbd 

Priority:  major  Milestone:  sage5.10 
Component:  packages: standard  Keywords:  ATLAS spkg 
Cc:  dimpase, fbissey, leif, kcrisman  Merged in:  
Authors:  Volker Braun  Reviewers:  Benjamin Jones, KarlDieter Crisman, Dmitrii Pasechnik, Georg Weber, François Bissey, John Palmieri 
Report Upstream:  Reported upstream. No feedback yet.  Work issues:  
Branch:  Commit:  
Dependencies:  #13160, #13395, #13392, #13416, #12994, #9906, #12883, #13123, #13415  Stopgaps: 
Description (last modified by )
The new atlas release now builds netlib lapack itself, so the lapack tarball is now included in the ATLAS spkg.
 Updated to newest upstream source, various patches are no longer required
SAGE_ATLAS_LIB=path
now searches inpath/libatlas.so
instead ofpath/lib/libatlas.so
so it works for people with atlas in/lib64
, too. Threading is now enabled by default
 Flush before
os.system
(#13210)
Upstream has made some attempt at changing the layout of the shared libraries, which is now different from the static libraries. The atlas spkg contains a stub autoconf/libtools project that unpacks the static libraries and repacks them into equivalent shared libraries.
By default, ATLAS will now try twice to get timings and fail immediately if throttling is enabled. If autotuning fails build with SAGE_ATLAS_ARCH=fast
, and if that fails with SAGE_ATLAS_ARCH=base
. On x86, the fast and base targets are the new ATLAS generic targets x86SSE3 and x86SSE2/x86x87.
The updated cvxopt spkg fixes a blas path issue on Darwin.
Updated spkgs:
 http://www.stp.dias.ie/~vbraun/Sage/spkg/atlas3.10.0.spkg
 http://www.stp.dias.ie/~vbraun/Sage/spkg/cvxopt1.1.5.p1.spkg
Apply 10508_root_after_13415.patch to the SAGE_ROOT repository and trac_10508_doctest.patch, trac_10508_update_atlas_docs.patch to the Sage repository.
Remove the lapack and blas packages.
Change History (243)
comment:1 Changed 11 years ago by
comment:2 Changed 11 years ago by
 Cc dimpase added
comment:3 Changed 11 years ago by
 Status changed from new to needs_info
Does it mean that LAPACK spkg can be removed, too?
comment:4 Changed 11 years ago by
Yes, the lapack spkg can be removed.
I'm still trying to debug some issues with linbox...
comment:5 Changed 11 years ago by
 Cc fbissey added
BLAS can also be removed if we go with this. f2c which was used before we got ATLAS to provide cblas by f2cing the BLAS package should also be removed (I think it listed in scipy's dependency only).
comment:6 followup: ↓ 7 Changed 11 years ago by
on 32bit x86 Linux (Debian squeeze) I get the following, when trying to install the spkg (applied the patches to a pristine Sage 4.6.1.alpha3):
... make j1 libatlas.so libptf77blas.so libf77blas.so \ libptcblas.so libcblas.so liblapack.so make[3]: Entering directory `/usr/local/src/sage/sage4.6.1.alpha3/spkg/build/atlas3.9.32/ATLASbuild/lib' ld melf_i386 shared soname /usr/local/src/sage/sage4.6.1.alpha3/local/lib/libatlas.so o libatlas.so \ rpathlink /usr/local/src/sage/sage4.6.1.alpha3/local/lib \ wholearchive libatlas.a nowholearchive lc lm make[3]: *** No rule to make target `libptf77blas.a', needed by `libptf77blas.so'. Stop. make[3]: Leaving directory `/usr/local/src/sage/sage4.6.1.alpha3/spkg/build/at las3.9.32/ATLASbuild/lib' make[2]: *** [ptshared] Error 2 make[2]: Leaving directory `/usr/local/src/sage/sage4.6.1.alpha3/spkg/build/at las3.9.32/ATLASbuild/lib' Configuration: SAGE_LOCAL: /usr/local/src/sage/sage4.6.1.alpha3/local linker_Solaris?: False PPC?: False SPKG_DIR: /usr/local/src/sage/sage4.6.1.alpha3/spkg/build/atlas3.9.32 linker_GNU?: True ld: GNU system: Linux Darwin?: False machine: i686 fortran: gfortran Solaris?: False fortran_g95?: False bits: 32bit CYGWIN?: False SPARC?: False fortran_GNU?: True FreeBSD?: False 32bit?: True Linux?: True 64bit?: False Intel?: False processor:
comment:7 in reply to: ↑ 6 Changed 11 years ago by
Replying to dimpase:
on 32bit x86 Linux (Debian squeeze) I get the following, when trying to install the spkg (applied the patches to a pristine Sage 4.6.1.alpha3):
complete install.log is here: http://boxen.math.washington.edu/home/dima/tmp/installalt3.9.log.gz
comment:8 followup: ↓ 9 Changed 11 years ago by
Hi Dima,
I think the problem is
make[6]: Entering directory `/usr/local/src/sage/sage4.6.1.alpha3/spkg/build/atlas3.9.32/ATLASbuild/tune/sysinfo' gcc c DL2SIZE=4194304 I/usr/local/src/sage/sage4.6.1.alpha3/spkg/build/atlas3.9.32/ATLASbuild/include I/usr/local/src/sage/sage4.6.1.alpha3/spkg/build/atlas3.9.32/ATLASbuild/../src//include I/usr/local/src/sage/sage4.6.1.alpha3/spkg/build/atlas3.9.32/ATLASbuild/../src//include/contrib DAdd_ DF77_INTEGER=int DStringSunStyle DATL_OS_Linux DATL_ARCH_CoreDuo DATL_CPUMHZ=800 DATL_SSE3 DATL_SSE2 DATL_SSE1 DATL_GAS_x8632 fomitframepointer O3 mfpmath=387 fPIC m32 /usr/local/src/sage/sage4.6.1.alpha3/spkg/build/atlas3.9.32/ATLASbuild/../src//tune/sysinfo/findNT.c gcc DL2SIZE=4194304 I/usr/local/src/sage/sage4.6.1.alpha3/spkg/build/atlas3.9.32/ATLASbuild/include I/usr/local/src/sage/sage4.6.1.alpha3/spkg/build/atlas3.9.32/ATLASbuild/../src//include I/usr/local/src/sage/sage4.6.1.alpha3/spkg/build/atlas3.9.32/ATLASbuild/../src//include/contrib DAdd_ DF77_INTEGER=int DStringSunStyle DATL_OS_Linux DATL_ARCH_CoreDuo DATL_CPUMHZ=800 DATL_SSE3 DATL_SSE2 DATL_SSE1 DATL_GAS_x8632 fomitframepointer O3 mfpmath=387 fPIC m32 o xfindNT findNT.o ATL_walltime.o lm /usr/lib/crt1.o: In function `_start': (.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status make[6]: *** [xfindNT] Error 1
This fails because ATL_NCPU
is not set. Do you have a singlecore processor? I guess the threaded libraries are not built in that case.
comment:9 in reply to: ↑ 8 ; followup: ↓ 18 Changed 11 years ago by
Replying to vbraun:
This fails because
ATL_NCPU
is not set. Do you have a singlecore processor? I guess the threaded libraries are not built in that case.
yes, it's singlecore. An old Pentium M. (Atlas 3.8 spkg does not build on it, at all)
comment:10 followup: ↓ 11 Changed 11 years ago by
I changed the spkginstall
to make only singlethreaded shared libraries if necessary. Should work now.
For simplicity, I made spkgs for cvxopts and sage_scripts. So you need to add
http://www.stp.dias.ie/~vbraun/Sage/spkg/atlas3.9.32.spkg http://www.stp.dias.ie/~vbraun/Sage/spkg/cvxopt1.1.3.p0.spkg http://www.stp.dias.ie/~vbraun/Sage/spkg/sage_scripts4.6.1.alpha3.p0.spkg
to $SAGE_ROOT/spkg/standard
and then
 replace
spkg/install
with the attached version (Note thatsage_scripts
overwrites this file during installation, aargh)  replace
spkg/standard/deps
with the attached version.
I'm still having doctest errors with linbox...
comment:11 in reply to: ↑ 10 Changed 11 years ago by
Replying to vbraun:
I changed the
spkginstall
to make only singlethreaded shared libraries if necessary. Should work now.
It builds OK, but then testlong gives quite a bit of failures:
The following tests failed: sage t long force_lib "devel/sage/doc/en/bordeaux_2008/elliptic_curves.rst" sage t long force_lib "devel/sage/sage/modular/modsym/space.py" sage t long force_lib "devel/sage/sage/modular/modsym/tests.py" sage t long force_lib "devel/sage/sage/modular/modsym/subspace.py" sage t long force_lib "devel/sage/sage/modular/modsym/ambient.py" sage t long force_lib "devel/sage/sage/modular/modform/space.py" sage t long force_lib "devel/sage/sage/modular/modform/element.py" sage t long force_lib "devel/sage/sage/modular/modform/ambient.py" sage t long force_lib "devel/sage/sage/modular/hecke/submodule.py" sage t long force_lib "devel/sage/sage/modular/abvar/abvar.py" sage t long force_lib "devel/sage/sage/modular/abvar/torsion_subgroup.py" sage t long force_lib "devel/sage/sage/modular/abvar/cuspidal_subgroup.py" sage t long force_lib "devel/sage/sage/modular/abvar/finite_subgroup.py" sage t long force_lib "devel/sage/sage/matrix/matrix_integer_dense.pyx" sage t long force_lib "devel/sage/sage/matrix/matrix_integer_dense_hnf.py" sage t long force_lib "devel/sage/sage/rings/qqbar.py" sage t long force_lib "devel/sage/sage/finance/time_series.pyx" sage t long force_lib "devel/sage/sage/schemes/elliptic_curves/padic_lseries.py" sage t long force_lib "devel/sage/sage/schemes/elliptic_curves/ell_modular_symbols.py" sage t long force_lib "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py" sage t long force_lib "devel/sage/sage/schemes/elliptic_curves/sha_tate.py" Total time for all tests: 30045.4 seconds
I do not know how many of them are Atlas related, though. The log is here: http://boxen.math.washington.edu/home/dima/tmp/testlongatl3.9.log
comment:12 followup: ↓ 13 Changed 11 years ago by
A lot of it is probably related. Was this a build from scratch? linbox calls seem to be particularly affected, there are a lot of failures in that path: sage.matrix.matrix_integer_dense.Matrix_integer_dense._charpoly_linbox stuff going through: sage.matrix.matrix_rational_dense.Matrix_rational_dense.right_kernel is also affected and that smells like atlas at work too.
I must say we have observed a number of failures related to ATLAS3.9.23 in sageongentoo: https://github.com/cschwan/sageongentoo/issues#issue/3 you have failure there too but not due to iml/ATLAS as far as I can see. https://github.com/cschwan/sageongentoo/issues#issue/6 more subtle. I see you have the failure with devel/sage/sage/finance/time_series.pyx you may want to look the comment I wrote about it in the section "known test failures for Sage on Gentoo": https://github.com/cschwan/sageongentoo/wiki/Knowntestfailures note that sageongentoo can use (c)blasreference, ATLAS or gslcblas or some combinations  in fact amd and intel libraries could in principle be used but no one I know has tried. http://www.gentoo.org/proj/en/science/blaslapack.xml
Not sure about the SIGFPE, it could come from a result rounded to 0 or the like.
comment:13 in reply to: ↑ 12 Changed 11 years ago by
Replying to fbissey:
A lot of it is probably related. Was this a build from scratch?
yes, it's a build from scratch, on the same machine (old Pentium M) as already discussed above.
linbox calls seem to be particularly affected, there are a lot of failures in that path:
I wonder if these are Atlas bugs, or Linbox bugs...
One should try an OSX build.
comment:14 followup: ↓ 15 Changed 11 years ago by
why OS X in particular? I could do that but not before the 5th of January, when my university reopens. Ok I could do it before that but I'll enjoy the break a little bit more :)
comment:15 in reply to: ↑ 14 ; followup: ↓ 16 Changed 11 years ago by
Replying to fbissey:
why OS X in particular? I could do that but not before the 5th of January, when my university reopens. Ok I could do it before that but I'll enjoy the break a little bit more :)
Or does OSX remain disabled for Atlas, i.e. it's not built?
comment:16 in reply to: ↑ 15 Changed 11 years ago by
Replying to dimpase:
Replying to fbissey:
why OS X in particular? I could do that but not before the 5th of January, when my university reopens. Ok I could do it before that but I'll enjoy the break a little bit more :)
Or does OSX remain disabled for Atlas, i.e. it's not built?
I had forgotten about that. I checked the spkg and ATLAS is not built on cygwin and OS X. So it makes sense.
comment:17 followup: ↓ 20 Changed 11 years ago by
I get the same doctest errors. Most of them are linbox related. The SIGFPE is from converting a NAN into a GMP integer, but I haven't gotten to the root of the NAN yet. In trying to debug this I've noticed that there are a bunch of valgrind warnings in the linbox code path we are using. I've asked some more specific questions on the linboxuse mailinglist:
https://groups.google.com/d/topic/linboxuse/N3QNNOQuTAc/discussion
But so far no final conclusion.
comment:18 in reply to: ↑ 9 ; followup: ↓ 19 Changed 11 years ago by
Replying to dimpase:
Replying to vbraun:
This fails because
ATL_NCPU
is not set. Do you have a singlecore processor? I guess the threaded libraries are not built in that case.yes, it's singlecore. An old Pentium M. (Atlas 3.8 spkg does not build on it, at all)
I notice you say it is a Pentium M, yet ATLAS is compiling things with the assumption that it is a coreduo: DATL_ARCH_CoreDuo DATL_CPUMHZ=800 DATL_SSE3 DATL_SSE2 DATL_SSE1 DATL_GAS_x8632 I am guessing the speed is right but the rest is not. Was your successful build using these parameters? I had in one instance a nonworking ATLAS because the cpu type was misdetected (wanted to use sse3 when it didn't have them). The build was curiously successful but the library was unusable.
comment:19 in reply to: ↑ 18 Changed 11 years ago by
Replying to fbissey:
Replying to dimpase:
Replying to vbraun:
This fails because
ATL_NCPU
is not set. Do you have a singlecore processor? I guess the threaded libraries are not built in that case.yes, it's singlecore. An old Pentium M. (Atlas 3.8 spkg does not build on it, at all)
I notice you say it is a Pentium M, yet ATLAS is compiling things with the assumption that it is a coreduo: DATL_ARCH_CoreDuo DATL_CPUMHZ=800 DATL_SSE3 DATL_SSE2 DATL_SSE1 DATL_GAS_x8632 I am guessing the speed is right but the rest is not. Was your successful build using these parameters? I had in one instance a nonworking ATLAS because the cpu type was misdetected (wanted to use sse3 when it didn't have them). The build was curiously successful but the library was unusable.
The processor is Pentium M Banias 1.1GHz, http://ark.intel.com/Product.aspx?id=27600 (according to GotoBlas? installation procedure :))
The Atlas built is not totally useless, it works for many doctests. By the way, 3.8 also thinks it's a CoreDuo?. And it works. I saw somewhere a note that it's OK.
comment:20 in reply to: ↑ 17 Changed 11 years ago by
Replying to vbraun:
I get the same doctest errors. Most of them are linbox related. The SIGFPE is from converting a NAN into a GMP integer, but I haven't gotten to the root of the NAN yet. In trying to debug this I've noticed that there are a bunch of valgrind warnings in the linbox code path we are using. I've asked some more specific questions on the linboxuse mailinglist:
https://groups.google.com/d/topic/linboxuse/N3QNNOQuTAc/discussion
But so far no final conclusion.
Converting a NAN into a GMP integer is exactly what was happening in https://github.com/cschwan/sageongentoo/issues/3 and it didn't happen when using gslcblas. I will do a full build of sageongentoo with 3.9.40 (or 41) and see if I can see anything.
comment:21 Changed 11 years ago by
Yuck, still got problems leading to linbox, I got the ones leading to iml too. Note that using another cblas like gslcblas/openblas/reference(netlib) all these problems disappear which seem to indicate that there is something going on in ATLAS itself or that all the others gets it wrong (I realise that on a stock sage you may have trouble compiling iml with anything else than ATLAS, it requires some patching to the configure script to be able to do so).
comment:22 Changed 11 years ago by
It may be worth noting that new released are available for both stable and development:
http://sourceforge.net/projects/mathatlas/files/Stable/3.8.4/Stable http://sourceforge.net/projects/mathatlas/files/Developer%20%28unstable%29/3.9.41/Unstable
comment:23 Changed 11 years ago by
I have 3.9.41 now, the only difference was it compiled faster because there was tuning for my cpu. But we could investigate 3.8.4. Thanks for pointing it is out, some of us (me at least) didn't think it would ever happen. We may have a stable ATLAS supporting newer CPUs at last, and it looks like I could test it quickly.
comment:24 Changed 11 years ago by
OK 3.8.4 doesn't suffer from any of the drawbacks that are apparent in 3.9.23+.
The big drawback is that it doesn't build lapack nicely on its own, provided we point to the sources like the latest 3.9.xx do. That means spkginstall would need a little bit more work.
Opinions?
comment:25 Changed 11 years ago by
Can we keep this ticket focused on the development version of atlas and discuss the stable ATLAS on #10226? I updated the spkg on the latter ticket to the new stable ATLAS release.
comment:26 Changed 11 years ago by
Sure. My current opinion and that's something I am pushing to sageongentoo users is to avoid ATLAS 3.9.xx for the time being. It is possible that ATLAS3.9.xx is doing something permissible that iml and linbox are not ready to catch. My line of thought is that I remember that some algorithm in iml takes the inverse of a result returned by cblas. If the result is 0 instead of a small value we may have our NaN, more likely some result from ATLAS is a NaN.
comment:27 Changed 11 years ago by
 Cc leif added
Note that you can copy updated spkgs into spkg/standard/
and then do
env SAGE_UPGRADING=yes make build
to rebuild all dependent packages.
(We should perhaps add make
targets for that to the toplevel Makefile and document them in the Developer's Guide, as this is currently just a sideeffect of the effort to make upgrading work.)
If you at the same time need to apply patches to the Sage library, things get a bit more complicated, as e.g. Sage switches to the main
branch before reinstalling the Sage library package. One safe way is to first apply the patches, create a new sagex.y.zwhatever
spkg (with devel/sage/spkgdist
) and replace the one in spkg/standard/
with that one (or at least make sure newest_version
will pick up the right one).
Note that the extension modules' dependencies in module_list.py
are currently far from complete. #8664 adds some in a generic way by adding them automatically in setup.py
, i.e. lets modules also depend on the headers of the libraries they use (which [only] works if the headers' mtimes get modified / updated during installation of their corresponding libraries). The dumb alternative is to run sage baforce
after an "upgrade" process.
comment:28 followup: ↓ 29 Changed 11 years ago by
Ping.
comment:29 in reply to: ↑ 28 Changed 11 years ago by
Replying to leif:
Ping.
just fired up my vintage MacOSX 32bit Powerbbok PPC... Will know more in, like, 12 hours...
comment:30 followup: ↓ 31 Changed 11 years ago by
Several issues:
 atlas is now at version 3.9.49 (last I checked)
 I have reports of it failling to build on some old opterons
 @dimpase: do you need atlas on OS X ppc? Don't you use vectorize like the other OS X?
 I haven't checked but I am quite sure from other reports that cblas_dgem{m,v} is still buggy (someone posted that R built against that Atlas lapack was giving them trouble and R upstream pointed the finger to Atlas).
comment:31 in reply to: ↑ 30 Changed 11 years ago by
Replying to fbissey:
Several issues:
 atlas is now at version 3.9.49 (last I checked)
 I have reports of it failling to build on some old opterons
so what? I have a 5year old 32bit Intel laptop on which the sagecurrent Atlas does not build.
 @dimpase: do you need atlas on OS X ppc? Don't you use vectorize like the other OS X?
indeed. But that's for #10509. Oops, was posting on the wrong ticket...
comment:32 Changed 10 years ago by
With respect to comment:33:ticket:12011, should this be closed as a dup of #12011?
comment:33 Changed 10 years ago by
 Status changed from needs_info to needs_review
propose to close this one and refer to #12011 the the continuation of the upgrade work.
comment:34 Changed 10 years ago by
 Milestone changed from sage5.0 to sageduplicate/invalid/wontfix
 Status changed from needs_review to positive_review
I would say #12011 is a duplicate of my ticket but oh well ;)
comment:35 Changed 10 years ago by
 Description modified (diff)
 Milestone changed from sageduplicate/invalid/wontfix to sage5.0
 Status changed from positive_review to needs_work
 Summary changed from Update ATLAS to version 3.9.32 to Update ATLAS to version 3.9.x
Seems like #12011 isn't a duplicate after all...
comment:36 Changed 10 years ago by
 Description modified (diff)
comment:37 Changed 10 years ago by
 Description modified (diff)
comment:38 Changed 10 years ago by
 Milestone changed from sage5.1 to sage5.3
Obviously, the patches to spkg/install
and spkg/standard/deps
must be rebased.
comment:39 Changed 10 years ago by
It makes a lot more sense to me to put the LAPACK
tarball at the top level of the spkg instead of in patches/
.
patches/ATLASlib/autom4te.cache
should be removed.
comment:40 Changed 10 years ago by
I don't like using assert
for control flow, because that's not what it's meant for.
Why not replace those by (see #13210)
if rc != 0: print "Error: foo" sys.exit(rc)
comment:41 Changed 10 years ago by
There is something wrong with the history in SPKG.txt
(atlas3.8.4 is completely missing and there is atlas3.9.68 for #12011 which never got merged)
comment:42 followup: ↓ 44 Changed 10 years ago by
I don't have any strong opinion on where to put the lapack tarball, except that our convention of only allowing a single src/
directory is shortsighted.
Note that I'm not using assertions for control flow, i.e. I'm not using
try: <command> except AssertionError: <alternative>
Note that you could theoretically also catch the SystemExit
exception, so sys.exit()
isn't different from assert
in that regard. I'm only using assertions to ensure the following contract holds: spkginstall
completes successfully only if the relevant atlas configure/make completed with rc==0
I'll replace the asserts by something that returns rc as exit code, though.
comment:43 Changed 10 years ago by
 Description modified (diff)
comment:44 in reply to: ↑ 42 Changed 10 years ago by
Replying to vbraun:
I'm only using assertions to ensure the following contract holds:
spkginstall
completes successfully only if the relevant atlas configure/make completed withrc==0
I think (IMHO but I might be wrong) that assertions should be used only in a situation where an assertion being false indicates a bug in the program. If rc != 0
in spkginstall
, that is an ordinary error condition, not a bug in the spkginstall
script.
comment:45 followup: ↓ 46 Changed 10 years ago by
Starting from sage5.1, I get one doctest failure:
File "/release/merger/sage5.1atlas/devel/sagemain/sage/rings/polynomial/polynomial_element.pyx", line 1039: sage: parent(poly)([ 0.0 if abs(c)<=1e14 else c for c in poly.coeffs() ]) Expected: 1.0 Got: 1.02140518266e14*x^2 + 1.0
comment:46 in reply to: ↑ 45 Changed 10 years ago by
Replying to jdemeyer:
Starting from sage5.1, I get one doctest failure:
sage: parent(poly)([ 0.0 if abs(c)<=1e14 else c for c in poly.coeffs() ])
it's most probably not at Atlas problem, but rather that 1e14 (any solid rationale behind this choice? I guess not.) needs to be adjusted.
comment:47 Changed 10 years ago by
 Reviewers set to Benjamin Jones
Testing in sage5.1.rc1 on x86_64 debian Linux:
$ uname a Linux sage 2.6.32 #1 SMP Fri Sep 2 21:08:57 CDT 2011 x86_64 GNU/Linux $ head 18 /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 44 model name : Intel(R) Xeon(R) CPU X5690 @ 3.47GHz stepping : 2 cpu MHz : 3465.790 cache size : 12288 KB fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat bogomips : 6931.58 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management:
BEFORE new ATLAS spkg
sage t "devel/sagemain/sage/modular/modsym/ambient.py" [11.6 s] sage t "devel/sagemain/sage/modular/hecke/ambient_module.py" [4.2 s] sage t "devel/sagemain/sage/modular/hecke/hecke_operator.py" [3.0 s]
AFTER new spkg
 untar'd fresh sage5.1.rc1
 replaced atlas3.8.4.p1.spkg with atlas3.9.85.spkg
 make build
SPKG build log: http://sage.math.washington.edu/home/bjones/atlas3.9.85.log
Build atlas3.9.85
real 11m18.595s user 11m15.906s sys 2m56.099s Successfully installed atlas3.9.85
Tests
sage t "devel/sagemain/sage/modular/modsym/ambient.py" [11.6 s] sage t "devel/sagemain/sage/modular/hecke/ambient_module.py" [4.2 s] sage t "devel/sagemain/sage/modular/hecke/hecke_operator.py" [3.1 s]
All tests
$ make ptestlong ... All tests passed! Total time for all tests: 1282.1 seconds
comment:48 Changed 10 years ago by
3.10.0 has just been released a few hours ago. Do we try to go for it? Like Jeroen remarked there may be tolerance issues depending on the hardware. I know I have one when using openblas instead of ATLAS.
comment:49 Changed 10 years ago by
 Description modified (diff)
 Status changed from needs_work to needs_review
 Summary changed from Update ATLAS to version 3.9.x to Update ATLAS to stable version 3.10
comment:50 followup: ↓ 51 Changed 10 years ago by
The new spkg will attempt to build on OSX if SAGE_ATLAS_ARCH
is set. Untested, but a start.
I also am planning to allow SAGE_ATLAS_LIB=system
and use ldconfig p
to get the system atlas, if available. Though perhaps we should do that in a later version. This spkg seems to fix some build issues that people reported on the sage mailinglists so it might be good to get it in sooner rather than later.
comment:51 in reply to: ↑ 50 Changed 10 years ago by
Replying to vbraun:
so it might be good to get it in sooner rather than later.
+1, let's not worry now about changing the working of SAGE_ATLAS_LIB
.
comment:52 Changed 10 years ago by
 Dependencies set to sage5.2.beta0
comment:53 Changed 10 years ago by
 Description modified (diff)
comment:54 Changed 10 years ago by
 Description modified (diff)
comment:55 Changed 10 years ago by
In spkginstall
, I find it confusing that you have a function build()
which calls configure()
and make_atlas()
.
I would get rid of build()
and simply call configure()
and make_atlas()
directly.
comment:56 Changed 10 years ago by
 Status changed from needs_review to needs_work
About SAGE_FAT_BINARY
: at one point you are checking
os.environ.has_key('SAGE_FAT_BINARY')
and at another you are checking
os.environ.get('SAGE_FAT_BINARY', 'no') == 'yes' and conf['Intel?']
I think the correct check is
os.environ.get('SAGE_FAT_BINARY', 'no') == 'yes'
"SAGE_FAT_BINARY" has evolved to mean "build a generic binary on any processor", so it's not Intel specific anymore. Just call configure_base()
.
comment:57 Changed 10 years ago by
Somebody needs to review 10508_doctest.patch
comment:58 Changed 10 years ago by
Detail: in system_with_flush()
, your print
command should not have a space after "Running". The space is automatically added by print
.
comment:59 Changed 10 years ago by
Updated spkg to remove the space and make the SAGE_FAT_BINARY
check uniform.
I'm fine with the doctests patch...
comment:60 Changed 10 years ago by
I'm always calling build()
except in one place where I want to allow configure()
to fail (because throttling is enabled).
comment:61 Changed 10 years ago by
Is this expected? Compare the build time on arando (Ubuntu 12.04 i386):
real 104m44.021s user 97m25.753s sys 1m18.157s Successfully installed atlas3.8.4.p1
real 259m50.222s user 233m21.879s sys 7m38.405s Successfully installed atlas3.10.0
comment:62 Changed 10 years ago by
 Status changed from needs_work to needs_review
I've noticed before that the build time for the "generic" binary is rather long. Its not entirely generic, it is still doing timing for cache edges. But the result will be a working library, it won't probe funky asm implementations that other CPUs might not support. I'll ask on the ATLAS mailinglist for clarification.
comment:63 followup: ↓ 64 Changed 10 years ago by
Timing on x86_64 with SAGE_FAT_BINARY=yes
on sage.math:
real 139m50.733s user 134m30.710s sys 7m12.390s Successfully installed atlas3.8.4.p1
real 350m5.662s user 330m23.460s sys 22m1.010s Successfully installed atlas3.10.0
Why does the new ATLAS take so much longer to build than the old one?
comment:64 in reply to: ↑ 63 Changed 10 years ago by
Replying to jdemeyer:
Timing on x86_64 with
SAGE_FAT_BINARY=yes
on sage.math:real 139m50.733s user 134m30.710s sys 7m12.390s Successfully installed atlas3.8.4.p1real 350m5.662s user 330m23.460s sys 22m1.010s Successfully installed atlas3.10.0Why does the new ATLAS take so much longer to build than the old one?
I can beat that:
Finished installing shared ATLAS library. real 821m14.881s user 739m58.560s sys 58m23.440s Successfully installed atlas3.10.0
(That's with sage f ...
on an otherwise idle machine, an AMD Fusion E450 running Ubuntu 10.04.4 LTS x86_64.)
It took far more time than building all of Sage [in parallel, on that dualcore CPU], including the old ATLAS spkg. I currently have no figures for a separate ATLAS 3.8.4 build, but the timings from previous parallel Sage builds on that machine vary between
real 214m52.096s user 175m5.390s sys 9m56.210s Successfully installed atlas3.8.4.p1
and
real 256m32.949s user 217m30.760s sys 10m31.050s Successfully installed atlas3.8.4.p1
(The LAPACK and BLAS spkg build times in these builds are a few minutes and less than one minute [wall time], respectively.)
I was actually hoping ATLAS 3.9.x / 3.10 meanwhile "knows" these AMD CPUs and therefore builds at least a bit faster...
comment:65 Changed 10 years ago by
FWIW, ptestlong
passed (after rebuilding all dependent packages) with Sage 5.2.beta0 (without applying the doctest patch).
comment:66 Changed 10 years ago by
We have noticed the building time increase in Gentoo as well. At 3.9.82 I think. Apparently they have changed how they detect the compiler and that's what causing the spike. But it seem fixed in 3.10.0 unless we are carrying a specific patch in Gentoo
Fri Jun 29 13:42:08 2012 >>> scilibs/atlas3.9.80 merge time: 8 minutes and 4 seconds. Wed Jul 4 14:56:21 2012 >>> scilibs/atlas3.9.82 merge time: 3 hours, 54 minutes and 30 seconds. Wed Jul 11 11:11:23 2012 >>> scilibs/atlas3.10.0 merge time: 8 minutes and 34 seconds.
comment:67 Changed 10 years ago by
If I set SAGE_ATLAS_ARCH=Corei2,AVX,SSE3,SSE2,SSE1 then I can also compile atlas3.10.0 in about 10 minutes. The issue is only with the "generic" archdefs, which seem to be not sufficiently specialzied. I've raised this issue on the ATLAS mailinglist.
comment:68 Changed 10 years ago by
The updated atlas spkg also installs a script atlasconfig
in $SAGE_LOCAL/bin
which can be used to compute new architectural defaults. I need somebody on Linux i386 to first install the new spkg and then run
SAGE_FAT_BINARY=yes atlasconfig archdef
to grind out the archdefs for the i386 "generic" target. I'm currently doing this for x86_64, but I don't have a i386 machine. This will use sudo to turn off CPU throttling so you need to be a sudoer.
[vbraun@volkerdesktop sage5.2.beta1]$ ./local/bin/atlasconfig help usage: atlasconfig [h] [unthrottle PID] [archdef] (Re)Build ATLAS (http://mathatlas.sourceforge.net) according to the SAGE_ATLAS_ARCH environment variable optional arguments: h, help show this help message and exit unthrottle PID switch CPU throttling off until PID finishes archdef build archdef tarball and save it to the current directory
comment:69 followup: ↓ 70 Changed 10 years ago by
I've updated the spkg with new 64bit generic archdefs, this now builds in about 10 mins.
comment:70 in reply to: ↑ 69 Changed 10 years ago by
Replying to vbraun:
I've updated the spkg with new 64bit generic archdefs, this now builds in about 10 mins.
md5sum?
I incidentally just downloaded some new version (163f090f18bb8616e93617677a644cd8
) and triggered a full build from scratch.
comment:71 Changed 10 years ago by
The newest version is 8a16c9d39add1c6c3f37e13986e2a3cc and thats whats linked in the ticket.
comment:72 Changed 10 years ago by
The new version d33e9114156d8373fa61f957b379e029 changes the "fast" 64bit archdef to P4E64SSE3
.
It turns out that there are no 64bit generic archdefs, which might have been one reason for why ATLAS was slow to compile. The SPKG uses the existing 32bit archdefs or the 64bit one that I made. On x86 the spkg should produce a working ATLAS library within 1030 mins, and only go through the tuning process if either
 CPU throttling is disabled (
scaling_governor=performance
, needs root), or  SAGE_ATLAS_ARCH is explicitly set to something different from "base" / "fast".
comment:73 followup: ↓ 74 Changed 10 years ago by
PS: Surprisingly enough, the new ATLAS spkg actually compiled on OSX (bsd.math)! If you want to try yourself just set SAGE_ATLAS_ARCH="base"
to force building on OSX.
comment:74 in reply to: ↑ 73 Changed 10 years ago by
Replying to vbraun:
PS: Surprisingly enough, the new ATLAS spkg actually compiled on OSX (bsd.math)! If you want to try yourself just set
SAGE_ATLAS_ARCH="base"
to force building on OSX.
Very cool. I just got ATLAS to build on my OS X 10.6.8 machine setting SAGE_ATLAS_ARCH=Corei2
. Running long tests now.
comment:75 followup: ↓ 76 Changed 10 years ago by
Update: ATLAS3.10.0 built successfully on my OS X 10.6.8 machine with SAGE_ATLAS_ARCH=Corei2
, the build took approx. 16 mins. The build log is at http://sage.math.washington.edu/home/bjones/atlas3.10.0.log. Sage passes all make ptestlong
tests. The spkg looks very good to me. I'd give this a positive review, but maybe it should be tested by a few other reviewers on other platforms first.
comment:76 in reply to: ↑ 75 Changed 10 years ago by
Replying to benjaminfjones:
Update: ATLAS3.10.0 built successfully on my OS X 10.6.8 machine with
SAGE_ATLAS_ARCH=Corei2
, the build took approx. 16 mins. The build log is at http://sage.math.washington.edu/home/bjones/atlas3.10.0.log. Sage passes allmake ptestlong
tests. The spkg looks very good to me. I'd give this a positive review, but maybe it should be tested by a few other reviewers on other platforms first.
I've built it successfully on OS X 10.6.8 (with Core2 Duo) and setting SAGE_ATLAS_ARCH="base"
.
comment:77 Changed 10 years ago by
Well, there's at least room for nitpicking (a couple of typos and some inconsistencies as well as superfluous code in spkginstall
and probably configuration.py
, don't recall)... I'll maybe take a look at it again tomorrow, and probably provide a patch (provided Volker doesn't plan to make further major changes to these files).
How about also installing a user script for convenience to save the built ATLAS libraries to another place (for later use with SAGE_ATLAS_LIB
)?
Regarding the mentioned excessive tuning times, I also wonder whether we should use something like SAGE_ATLAS_ARCH=fast
(or base
) by default, i.e., only do selftuning if the user explicitly asks for it in some way. I guess the Sage Installation Guide needs to get updated anyway w.r.t. ATLAS and environment variables.
comment:78 Changed 10 years ago by
The root repo patch should get rebased for Sage 5.2.rc0.
comment:79 Changed 10 years ago by
On hawk (OpenSolaris):
DONE configure Finished configuring ATLAS. Running make j1 make[2]: Entering directory `/export/home/palmieri/testing/ATLAS/sage5.2.rc0/spkg/build/atlas3.1\ 0.0/ATLASbuild' make[2]: warning: jN forced in submake: disabling jobserver mode. make j1 f Make.top build make[3]: Entering directory `/export/home/palmieri/testing/ATLAS/sage5.2.rc0/spkg/build/atlas3.1\ 0.0/ATLASbuild' Make.top:1: Make.inc: No such file or directory Make.top:325: warning: overriding commands for target `/AtlasTest' Make.top:76: warning: ignoring old commands for target `/AtlasTest' make[3]: *** No rule to make target `Make.inc'. Stop. make[3]: Leaving directory `/export/home/palmieri/testing/ATLAS/sage5.2.rc0/spkg/build/atlas3.10\ .0/ATLASbuild' make[2]: *** [build] Error 2 make[2]: Leaving directory `/export/home/palmieri/testing/ATLAS/sage5.2.rc0/spkg/build/atlas3.10\ .0/ATLASbuild'  File "./spkginstall", line 478, in <module> assert_success(rc, bad='Failed to build ATLAS.', good='Finished building ATLAS core.') File "./spkginstall", line 74, in assert_success traceback.print_stack(file=sys.stdout)  Error: Failed to build ATLAS. real 4m10.778s user 0m7.766s sys 0m8.391s Successfully installed atlas3.10.0 Deleting temporary build directory /export/home/palmieri/testing/ATLAS/sage5.2.rc0/spkg/build/atlas3.10.0 Finished installing atlas3.10.0.spkg
I don't know why it's not building, but it shouldn't exit saying "Successfully installed atlas3.10.0". I added a print statement, and "rc" is 512. The documentation for sys.exit says that for the argument, "Most systems require it to be in the range 0127, and produce undefined results otherwise." We could instead do this:

spkginstall
diff git a/spkginstall b/spkginstall
a b def assert_success(rc, good=None, bad=No 74 74 traceback.print_stack(file=sys.stdout) 75 75 print ''*60 76 76 if bad is not None: 77 print 'Error: ', bad78 sys.exit( rc)77 sys.exit('Error: %s' % bad) 78 sys.exit(1) 79 79 80 80 ###################################################################### 81 81 ### Skip building ATLAS on specific systems
comment:80 Changed 10 years ago by
 Status changed from needs_review to needs_work
comment:81 followup: ↓ 93 Changed 10 years ago by
On Ubuntu 10.04.4 LTS x86_64 (AMD E450), with Sage 5.2.rc0 and SAGE_ATLAS_ARCH=fast
I get:
... Building using specific architecture. Fast configuration on Intel x86_64 compatible CPUs. Running configure with arch = P4E64SSE3, isa extensions ('SSE3', 'SSE2', 'SSE1'), archdef dir None Traceback (most recent call last): File "./spkginstall", line 454, in <module> rc = build() File "./spkginstall", line 447, in build rc = configure(arch, isa_ext, archdef_dir) File "./spkginstall", line 315, in configure cmd += ' A '+str(ATLAS_MACHTYPE.index(arch)) ValueError: tuple.index(x): x not in tuple real 0m0.701s user 0m0.090s sys 0m0.060s ************************************************************************ Error installing package atlas3.10.0 ************************************************************************
comment:82 Changed 10 years ago by
Built successfully on power7. A few oddities in the log but I don't think they are important
make j1 atlas_run atldir=/hpc/scratch/frb15/sandbox/sage5.1.beta5/spkg/build/atlas3.10.0/ATLASbuild exe=xprobe_comp redir=config1.out \ args="v 0 o atlconf.txt O 1 A 7 Si nof77 0 V 6 Fa ic 'fPIC' C sm 'gcc' Fa sm 'fPIC' C dm 'gcc' Fa dm 'fPIC' C sk 'gcc' Fa sk 'fPIC' C dk 'gcc' Fa dk 'fPIC' C xc 'gcc' Fa xc 'fPIC' Fa gc 'fPIC' C if 'sage_fortran' Fa if 'fPIC' b 64  d b /hpc/scratch/frb15/sandbox/sage5.1.beta5/spkg/build/atlas3.10.0/ATLASbuild" make[1]: Entering directory `/hpc/scratch/frb15/sandbox/sage5.1.beta5/spkg/build/atlas3.10.0/ATLASbuild' cd /hpc/scratch/frb15/sandbox/sage5.1.beta5/spkg/build/atlas3.10.0/ATLASbuild ; ./xprobe_comp v 0 o atlconf.txt O 1 A 7 Si nof77 0 V 6 Fa ic 'fPIC' C sm 'gcc' Fa sm 'fPIC' C dm 'gcc' Fa dm 'fPIC' C sk 'gcc' Fa sk 'fPIC' C dk 'gcc' Fa dk 'fPIC' C xc 'gcc ' Fa xc 'fPIC' Fa gc 'fPIC' C if 'sage_fortran' Fa if 'fPIC' b 64 d b /hpc/scratch/frb15/sandbox/sage5.1.beta5/spkg/build/atlas3 .10.0/ATLASbuild > config1.out sh: c: line 0: unexpected EOF while looking for matching ``' sh: c: line 1: syntax error: unexpected end of file sh: c: line 0: unexpected EOF while looking for matching ``' sh: c: line 1: syntax error: unexpected end of file sh: c: line 0: unexpected EOF while looking for matching ``' sh: c: line 1: syntax error: unexpected end of file sh: c: line 0: unexpected EOF while looking for matching ``' sh: c: line 1: syntax error: unexpected end of file sh: c: line 0: unexpected EOF while looking for matching ``' sh: c: line 1: syntax error: unexpected end of file probe_f2c.o: In function `ATL_tmpnam': /hpc/scratch/frb15/sandbox/sage5.1.beta5/spkg/build/atlas3.10.0/ATLASbuild/../src//CONFIG/include/atlas_sys.h:224: warning: the use of ` tmpnam' is dangerous, better use `mkstemp'
I noticed that libcblas.so is using rpath
ldd r local/lib/libcblas.so.2.1.0 linuxvdso64.so.1 => (0x0000040000000000) libatlas.so.2 => /hpc/scratch/frb15/sandbox/sage5.1.beta5/local/lib/libatlas.so.2 (0x0000040000060000) libpthread.so.0 => /lib64/power7/libpthread.so.0 (0x00000400008a0000) libm.so.6 => /lib64/power7/libm.so.6 (0x00000400008e0000) libc.so.6 => /lib64/power7/libc.so.6 (0x00000400009c0000) /lib64/ld64.so.1 (0x0000000024560000)
And that's from outside the sage shell. However for f77blas and presumably lapack, libgfortran is not rpathed (I am using sage gcc's spkg in this case).
That is important info if you want to put atlas libraries in another location.
I will run a few tests shortly.
comment:83 Changed 10 years ago by
Volker, do you still need architecture defaults for i386? I have access to an old laptop with a Centrino M processor that reports being i386 / i686 in uname a
and in /proc/cpuinfo:
cpu family 6 cpu model 13 Intel Pentium M
I haven't ever built Sage on it, I imagine it would take several years, but I'm willing to give it a try.
comment:84 followup: ↓ 85 Changed 10 years ago by
 John, I'm against changing the exit codes, we report whatever the subprocess spat out. So even if its >127, thats just what we were handed so clearly its a supported exit code.
I don't have an account on hawk, but in any case that should not stop us from shipping an updated ATLAS that fixes build issues on modern hard/software. We can always clean up secondtier platforms later. But do post the whole log, the error is likely further up.
 Leif, are you working on a patch? In
configure_fast()
, we should setarch = 'P4E'
instead ofP4E64SSE3
is added later. This is what causes your build failure.
 Francois: the weird messages are normal. The rpaths are set by libtools and are what libtools likes to set. As long as we set
LD_LIBRARY_PATH
this doesn't matter except when we distribute the binaries. This needs to be fixed some day in all shared libs but not on this ticket.
 Benjamin: no I don't need 32bit archdefs, this should be covered by what ATLAS already ships with. The atlas spkg should build relatively quickly now except for the cases in 72
comment:85 in reply to: ↑ 84 Changed 10 years ago by
Replying to vbraun:
 John, I'm against changing the exit codes, we report whatever the subprocess spat out. So even if its >127, thats just what we were handed so clearly its a supported exit code.
But after sys.exit(512)
, Python has return code of zero, on sage.math, OS X, and OpenSolaris. So sagespkg thinks the spkg installed correctly, which it clearly didn't. From the documentation for os.system, it looks to me that its output should be divided by 512 to get a return code suitable for sys.exit, but I'm not sure about that. However you want to fix it, it has to be changed: it's not acceptable for the compilation to fail but for spkginstall to have a return code of zero.
I don't have an account on hawk, but in any case that should not stop us from shipping an updated ATLAS that fixes build issues on modern hard/software. We can always clean up secondtier platforms later. But do post the whole log, the error is likely further up.
The log is posted at http://sage.math.washington.edu/home/palmieri/misc/atlas3.10.0.log.
comment:86 Changed 10 years ago by
Something along the following lines should be used to handle rc
, see http://docs.python.org/library/os.html
if os.WIFEXITED(rc): rc = os.WEXITSTATUS(rc) elif os.WIFSIGNALED(rc): rc = 128 + os.WTERMSIG(rc) else: raise SystemError("Unknown return value %i for os.system()"%rc)
comment:87 Changed 10 years ago by
I've investigated and reported the Solaris build issue upstream at https://sourceforge.net/tracker/?func=detail&aid=3545418&group_id=23725&atid=379483
comment:88 Changed 10 years ago by
The return value is actually the return value of os.system()
, which is described in http://docs.python.org/library/os.html#os.wait
To extract the exit status, we should just do sys.exit((rc >> 8) & 0x7f)
. Leif, are you working on the spkg right now?
comment:89 Changed 10 years ago by
The workaround for the Solaris build issue is to use the fqn for $CC
and sage_fortran
comment:90 Changed 10 years ago by
Since Leif apparently isn't around I implemented the fqn workaround for the Solaris build and the return status issues. Solaris build is still broken but now at a different place. Updated spkg at the same place, md5sum is 878695a26071cfe73a9977bd8413b748
.
comment:91 Changed 10 years ago by
This version now builds on hawk: log file here.
comment:92 Changed 10 years ago by
Sounds good! I updated the spkg with yet another SPARC Solaris fix, md5sum is 6dbcf22c920626380f2cba877cca4cb1
. Though still doesn't work on mark/skynet, but at least makes it now into the compile phase. In any case SPARC solaris issues shouldn't delay this ticket.
comment:93 in reply to: ↑ 81 ; followup: ↓ 94 Changed 10 years ago by
Replying to leif:
On Ubuntu 10.04.4 LTS x86_64 (AMD E450), with Sage 5.2.rc0 and
SAGE_ATLAS_ARCH=fast
I get:ValueError: tuple.index(x): x not in tuple
Using SAGE_ATLAS_ARCH=base
in contrast worked (and ptestlong
passed with Sage 5.2.rc0, FWIW):
real 34m12.187s user 30m3.170s sys 5m30.850s Successfully installed atlas3.10.0
Still not that fast, but approximately within your estimates...
comment:94 in reply to: ↑ 93 ; followup: ↓ 95 Changed 10 years ago by
Replying to leif:
real 34m12.187s
Thats pretty good for 18W TDP. I take it compiling all of Sage takes 2+ hours on that machine?
comment:95 in reply to: ↑ 94 ; followup: ↓ 103 Changed 10 years ago by
Replying to vbraun:
Replying to leif:
real 34m12.187s
Thats pretty good for 18W TDP. I take it compiling all of Sage takes 2+ hours on that machine?
Sure. Although ATLAS currently consumes only <= 9W ;)
Unfortunately ATLAS is built quite late (due to its odd dependency on Sage's Python  while your script is apparently designed to support Python 2.4 as well), so a fair amount of the time spent building Sage only one core is used (because the remaining packages directly or indirectly depend on ATLAS).
I reinstalled the updated spkg again with SAGE_ATLAS_ARCH=fast
:
real 40m20.227s user 36m26.220s sys 6m9.500s Successfully installed atlas3.10.0
comment:96 followup: ↓ 97 Changed 10 years ago by
An update: on hawk, I unpacked a sage5.2.rc0 tarball, replaced the old ATLAS spkg with this one, and built from scratch. There are a bunch of doctest failures:
The following tests failed: sage t long force_lib devel/sage/sage/matrix/matrix2.pyx # 12 doctests failed sage t long force_lib devel/sage/sage/misc/functional.py # 1 doctests failed sage t long force_lib devel/sage/sage/finance/time_series.pyx # 6 doctests failed sage t long force_lib devel/sage/sage/numerical/test.py # Killed/crashed sage t long force_lib devel/sage/sage/modular/modform/numerical.py # 3 doctests failed sage t long force_lib devel/sage/sage/numerical/optimize.py # Killed/crashed sage t long force_lib devel/sage/sage/matrix/matrix_double_dense.pyx # 68 doctests failed sage t long force_lib devel/sage/doc/en/a_tour_of_sage/index.rst # Killed/crashed sage t long force_lib devel/sage/doc/en/numerical_sage/cvxopt.rst # Killed/crashed sage t long force_lib devel/sage/doc/fr/a_tour_of_sage/index.rst # Killed/crashed sage t long force_lib devel/sage/doc/tr/a_tour_of_sage/index.rst # Killed/crashed sage t long force_lib devel/sage/sage/combinat/e_one_star.py # Killed/crashed
For example:
File "/export/home/palmieri/testing/ATLAS/sage5.2.rc0/devel/sagemain/sage/matrix/matrix2.pyx", line 8157: sage: (A  M*G).zero_at(10^12) Expected: [0.0 0.0 0.0] [0.0 0.0 0.0] [0.0 0.0 0.0] Got: [ 0.0 0.0 0.0] [ 0.10532733041 + 0.0950573490006*I 0.017805411596  0.0512258178986*I 0.0226596712913 + 0.0414519876977*I] [ 0.100615400305 + 0.0962034401538*I 0.0779990660567  0.0543172822202*I 0.057608664751 + 0.0154619373789*I]
and
File "/export/home/palmieri/testing/ATLAS/sage5.2.rc0/devel/sagemain/sage/misc/functional.py", line 1144: sage: norm(M) Expected: 10.6903311292 Got: 10.4323182134
I'll try to build again in case something wrong the first time.
comment:97 in reply to: ↑ 96 Changed 10 years ago by
Replying to jhpalmieri:
An update: on hawk, I unpacked a sage5.2.rc0 tarball, replaced the old ATLAS spkg with this one, and built from scratch. There are a bunch of doctest failures:
Did you apply the root repo patch (to remove the BLAS and LAPACK spkgs)?
comment:98 Changed 10 years ago by
Oops, no, I forgot. One more time...
comment:99 Changed 10 years ago by
Now Sage doesn't build on hawk, I guess due to the problems noted on #10509: cvxopt doesn't build, because it says
ld: fatal: library lblas: not found
I'll skip building cvxopt and continue with the rest of the build.
comment:100 followup: ↓ 109 Changed 10 years ago by
I don't think the cvxopt problem is due to #10509. The cvxopt spkg explicitly links against blas
, this is bad. From the cvxopt patches/setup.py.patch
:
+ libraries = ['m','lapack','gsl','blas','gslcblas','cblas','gfortran','atlas']
this is wrong, it should be f77blas
if the Fortran version is actually used or not there at all. Of course all modern systems have a libblas.so
somewhere so the linker finds it, notes that it is not used, and proceeds. Except that on Hawk, I guess, there is no systemwide libblas
. We should proceed removing blas in this ticket and then fix cvxopt on secondtier platforms later.
comment:101 Changed 10 years ago by
I meant that linking to blas was noted at #10509 as a possible problem, not that #10509 was causing this issue.
comment:102 Changed 10 years ago by
You are right, that the patch on #10509 should have been applied to cvxopt a long time ago then it wouldn't break here.
comment:103 in reply to: ↑ 95 ; followup: ↓ 110 Changed 10 years ago by
Replying to leif:
Replying to vbraun:
Replying to leif:
real 34m12.187s
Thats pretty good for 18W TDP. I take it compiling all of Sage takes 2+ hours on that machine?
[...]
I reinstalled the updated spkg again with
SAGE_ATLAS_ARCH=fast
:real 40m20.227s user 36m26.220s sys 6m9.500s Successfully installed atlas3.10.0
ROFL, with SAGE_ATLAS_ARCH="AMD64K10h,SSE3,SSE2,SSE1,3DNow"
(which involves selftuning) it took
real 36m15.153s user 31m23.290s sys 5m56.960s Successfully installed atlas3.10.0
Also a bit strange is that the timing for ptestlong
(all for Sage 5.2.rc0, GCC 4.4.3) was
base
<fast
<AMD64K10h
(i.e., fastest with SAGE_ATLAS_ARCH=base
), although I think at least during the last run the machine was partially loaded with other stuff as well, and clearly ptestlong
isn't very appropriate to benchmark ATLAS performance... ;)
[Not going to use the ATLAS tools for comparison right now, perhaps later...]
comment:104 Changed 10 years ago by
P.S.:
Another weird thing are (nonfatal w.r.t. the build) errors like
FlagCheck.c:1: error: bad value (ultrasparc) for mtune= switch FlagCheck.c:1: error: bad value (ultrasparc) for mtune= switch FlagCheck.c:1: error: bad value (ultrasparc) for mtune= switch FlagCheck.c:1: error: bad value (ultrasparc) for mtune= switch FlagCheck.c:1: error: bad value (armv7) for march= switch FlagCheck.c:1: error: bad value (armv7) for mtune= switch FlagCheck.c:1: error: bad value (ultrasparc) for mtune= switch FlagCheck.c:1: error: bad value (ultrasparc) for mtune= switch FlagCheck.c:1: error: bad value (ultrasparc) for mtune= switch FlagCheck.c:1: error: bad value (ultrasparc) for mtune= switch FlagCheck.c:1: error: bad value (970) for mtune= switch
even if one specifies the architecture (i.e., on x86).
comment:105 Changed 10 years ago by
On hawk: with the appropriate patches applied, I still get some test failures, but as far as I can tell, they're all due to cvxopt being broken. So it looks pretty good.
comment:106 followup: ↓ 108 Changed 10 years ago by
Is it intentional that static libraries no longer get installed (although built)?
comment:107 Changed 10 years ago by
On cvxopt I am doing a new spkg in #13160 I'll check what I have done there. My main issue with the current spkg is it is horribly overlinked.
comment:108 in reply to: ↑ 106 ; followup: ↓ 111 Changed 10 years ago by
Replying to leif:
Is it intentional that static libraries no longer get installed (although built)?
Upstream really only builds static libraries. But static libraries suck for our purposes. So yet, it is intentional that the static libraries are not installed.
comment:109 in reply to: ↑ 100 Changed 10 years ago by
Replying to vbraun:
I don't think the cvxopt problem is due to #10509. The cvxopt spkg explicitly links against
blas
, this is bad. From the cvxoptpatches/setup.py.patch
:+ libraries = ['m','lapack','gsl','blas','gslcblas','cblas','gfortran','atlas']this is wrong, it should be
f77blas
if the Fortran version is actually used or not there at all. Of course all modern systems have alibblas.so
somewhere so the linker finds it, notes that it is not used, and proceeds. Except that on Hawk, I guess, there is no systemwidelibblas
. We should proceed removing blas in this ticket and then fix cvxopt on secondtier platforms later.
Perhaps this ticket should get #13160 as a dependence. One thing I checked is that it appears to work on OSX 10.6.8, both with native blas/lapack, and with Atlas 3.10 from this ticket. I imagine #13160 can get finalized quickly.
comment:110 in reply to: ↑ 103 Changed 10 years ago by
Replying to leif:
[Not going to use the ATLAS tools for comparison right now, perhaps later...]
FWIW, while make time
works, make atlvat2.pdf ...
(to build ATLAS vs. ATLAS comparison charts) seems to be broken  for me it always fails with a buffer overflow.
comment:111 in reply to: ↑ 108 Changed 10 years ago by
Replying to vbraun:
Replying to leif:
Is it intentional that static libraries no longer get installed (although built)?
Upstream really only builds static libraries. But static libraries suck for our purposes. So yet, it is intentional that the static libraries are not installed.
Well, as long as also the shared libraries are present, they're (usually) preferred over the static ones (i.e., unless one explicitly asks for linking against the latter), so copying these into $SAGE_LOCAL/lib/
IMHO shouldn't hurt. (The static libraries are btw. needed to compare different ATLAS installations; the only way to "keep" them is to reinstall the ATLAS spkg with ./sage f s ...
or to set SAGE_KEEP_BUILT_SPKGS
, and manually copy them.)
Note that previously installed static ATLAS libraries currently don't get removed. Don't know whether that may cause trouble (e.g. with upgrading); see above.
comment:112 Changed 10 years ago by
Its true that it doesn't hurt to have the static libraries as long as you don't use them. This is like saying that a knife doesn't hurt until you are stabbed with it. True, but why put a sharp blade under the couch pillow in hopes that nobody will sit on it?
It would be nice to have some system to compare different atlas versions and compile runs, but thats definitely for another ticket. Ideally the atlasconfig
python script could save the atlas libraries in a private directory, for example by setting a special environment variable while building atlas. And then have some way to tabulate the performance of different installs.
comment:113 Changed 10 years ago by
 Dependencies changed from sage5.2.beta0 to #13160
 Status changed from needs_work to needs_review
I think the only remaining blocker is that it (or rather, cvxopt) doesn't build on hawk. Since I don't have an account, can someone test it (the spkg + patches from this ticket + the cvxopt spkg from #13160)? Everything else in this ticket has been reviewed already, we just have to check that the interaction with cvxopt is fixed on the last "fully supported" platform.
comment:114 Changed 10 years ago by
Cvxopt still doesn't build. I see the same error when using the ATLAS spkg here or when setting SAGE_ATLAS_LIB=/ATLAS32
. Here is the log.
Does the ATLAS spkg here build on skynet/mark (and Solaris on sparc in general)?
comment:115 Changed 10 years ago by
Why the heck is it not finding gsl? Oh I see the include line is actually wrong. I'll check the spkg but we should continue with cvxopt issues at #13160.
comment:116 Changed 10 years ago by
John, now that you verified that it works on Hawk is there anything else that prevents you from pressing the positive review button? ;)
comment:117 Changed 10 years ago by
I'm testing on a few skynet machines. Should I expect it to work on mark?
comment:118 followup: ↓ 119 Changed 10 years ago by
It worked for me on mark (sparc solaris)
comment:119 in reply to: ↑ 118 Changed 10 years ago by
Replying to vbraun:
It worked for me on mark (sparc solaris)
OMG cool, Skynet is back up. I was totally unaware of that!
comment:120 Changed 10 years ago by
I'm still not happy with "discarding" the built static libraries; there should at least be some convenient way to save them (other than SAGE_KEEP_BUILT_SPKGS=yes
or installing with sage (if) s ...
.)
Another issue is the extremely increased build time on some machines if one doesn't set SAGE_ATLAS_ARCH
. Don't know how we could handle that, but it certainly gives rise to a lot of user complaints.
comment:121 Changed 10 years ago by
P.S.: W.r.t. the "knife": If you don't want to install static libraries (somewhere), at least previous ones should get removed (or moved somewhere else) upon a successful ATLAS build.
comment:122 followup: ↓ 124 Changed 10 years ago by
Now that I added the generic 64bit archdefs the default build time (without setting SAGE_ATLAS_ARCH
) should be moderate on all x86 systems. I.e. less CPU time than building the rest of Sage.
Your suggestions about handling the static libraries are enhancement requests. By itself, its useless to keep a backup of the static libraries somewhere. I agree that one should keep them around and devise a way to benchmark them, but not on this ticket. Also I'm against attempting to delete stuff from previous installs unless it actively conflicts with the new spkg. Which it does not, the damage of statically linking is already done.
comment:123 Changed 10 years ago by
I'm willing to give this a positive review now. Leif, what about you? Can we defer your issues to a followup?
comment:124 in reply to: ↑ 122 ; followup: ↓ 126 Changed 10 years ago by
Replying to vbraun:
Now that I added the generic 64bit archdefs the default build time (without setting
SAGE_ATLAS_ARCH
) should be moderate on all x86 systems. I.e. less CPU time than building the rest of Sage.
Ok, hopefully...
Your suggestions about handling the static libraries are enhancement requests. By itself, its useless to keep a backup of the static libraries somewhere. I agree that one should keep them around and devise a way to benchmark them, but not on this ticket.
I'd rather say not installing them [anywhere] is a regression w.r.t. the previous spkg.
Also I'm against attempting to delete stuff from previous installs unless it actively conflicts with the new spkg. Which it does not, the damage of statically linking is already done.
If so, it shouldn't hurt to keep ATLAS installing them either... ;)
[I'd expect "more damage" when having different .a
and .so
library versions.]
comment:125 Changed 10 years ago by
I'm not wanting to hold up this ticket, but IMHO the Installation Guide should get updated, at least documenting the new atlasconfig
script.
comment:126 in reply to: ↑ 124 Changed 10 years ago by
Replying to leif:
I'd rather say not installing them [anywhere] is a regression w.r.t. the previous spkg.
Its a major improvement, not a regression!
If so, it shouldn't hurt to keep ATLAS installing them either... ;)
As I explained previously, thats not true. We have to change things to make them better. But we can't unlink the static linkage that has happened previously, so when you upgrade from an existing spkg you potentially keep the old code. And there is nothing a new atlas spkg can do about this. If you want to be sure that you don't have cruft statically linked you'll have to do a clean install. This is precisely why it was a bad idea to install static libraries previously.
comment:127 Changed 10 years ago by
 Description modified (diff)
I've added documentation to the installation guide for the atlasconfig script and updated the environment variables.
comment:128 Changed 10 years ago by
I note that on OS X, the test suite doesn't run, even if ATLAS is built. This could perhaps be dealt with on a followup ticket? Maybe only skip selftests if
"$UNAME" = "Darwin" a z "$SAGE_ATLAS_ARCH"
or something like that?
More seriously, I'm having problems with this on the skynet machine iras. I'm building Sage from scratch, using the spkgs from this ticket and #13160. The ATLAS build started about 15 hours ago, and nothing has been written to the log file for at least 6 hours. I'm going to quit and restart the build...
comment:129 followup: ↓ 130 Changed 10 years ago by
On skynet machine iras:
real 2251m2.189s user 2175m58.212s sys 16m29.112s
This is not really acceptable. And then:
RHS=74, nrm=184.678650 RHS=75, nrm=248.384750 RHS=76, nrm=291.507111 RHS=77, nrm=337.993896 RHS=78, nrm=335.039612 RHS=79, nrm=477.389954 RHS=80, nrm=334.815796 make[5]: *** [csanity_test] Error 1 make[5]: *** Waiting for unfinished jobs.... make[5]: Leaving directory `/home/palmieri/iras/sage5.2.10508/spkg/build/atlas\ 3.10.0/ATLASbuild/bin' make[4]: *** [sanity_test] Error 2 make[4]: Leaving directory `/home/palmieri/iras/sage5.2.10508/spkg/build/atlas\ 3.10.0/ATLASbuild/bin' make[3]: *** [sanity_test] Error 2 make[3]: Leaving directory `/home/palmieri/iras/sage5.2.10508/spkg/build/atlas\ 3.10.0/ATLASbuild' make[2]: *** [test] Error 2 make[2]: Leaving directory `/home/palmieri/iras/sage5.2.10508/spkg/build/atlas\ 3.10.0/ATLASbuild' An error occurred when running the ATLAS selftests.
comment:130 in reply to: ↑ 129 ; followup: ↓ 138 Changed 10 years ago by
Replying to jhpalmieri:
On skynet machine iras:
real 2251m2.189s user 2175m58.212s sys 16m29.112s
Ouch. How long did 3.8.4 take to build, and did you suspend the ECM background jobs? (They're back again...)
Presumably something to report upstream, but perhaps we can tweak it ourselves somehow.
comment:131 followups: ↓ 133 ↓ 136 Changed 10 years ago by
Clint Whaley (ATLAS developer) doesn't have access to Itanium any more, so its not surprising that it does a full search. If its too slow for you then get yourself a new computer ;) I'll have a look at the selftest issue, but it seems that the build/install works. Right?
I'd also like to remind everyone that this ticket, even if it doesn't pass its own testsuite on some dead arch, fixes actual issues with modern CPUs as reported on the mailinglist.
comment:132 Changed 10 years ago by
 Report Upstream changed from N/A to Reported upstream. No feedback yet.
comment:133 in reply to: ↑ 131 ; followup: ↓ 134 Changed 10 years ago by
Replying to vbraun:
Clint Whaley (ATLAS developer) doesn't have access to Itanium any more, so its not surprising that it does a full search. If its too slow for you then get yourself a new computer ;) I'll have a look at the selftest issue, but it seems that the build/install works. Right?
Can't one use the current ATLAS spkg on Itaniums instead of the new one? Or there are incompatibility problems?
Itaniums are not a dying breed, at least AFAIK Intels still plans to release a new Itanium chip this year. So just hoping that they'd be gone soon is too optimistic. Should we try getting Clint Whaley access to an Itanium machine?
comment:134 in reply to: ↑ 133 ; followup: ↓ 137 Changed 10 years ago by
Replying to dimpase:
Can't one use the current ATLAS spkg on Itaniums instead of the new one? Or there are incompatibility problems?
We can use a preinstalled ATLAS library on the buildbots. Given that this is by far the slowest part of the compile cycle, I think thats reasonable. We even do this officially on OSX where we always use the systemprovided BLAS. But perhaps easier would be to update the Itanium archdef so that it doesn't have to tune. I just started a compile on iras, but don't expect the answer too soon ;)
Itaniums are not a dying breed, at least AFAIK Intels still plans to release a new Itanium chip this year.
Well Intel made some unfortunate (for them) contractual commitments here... But ia64 is certainly not getting much love.
Should we try getting Clint Whaley access to an Itanium machine?
I've asked to that extend on the sageskynet list.
comment:135 Changed 10 years ago by
It worked on 2 machines I tested, but failed on a PIII machine  it turns out that Atlas 3.10.0 does not work on PIII but the fix is simple  see http://mathatlas.sourceforge.net/errata.html#piiisse2 for confirmation.
I've uploaded spkg containing fix for this to https://github.com/downloads/aginiewicz/spkgs/atlas3.10.0.spkg
comment:136 in reply to: ↑ 131 Changed 10 years ago by
Replying to vbraun:
I'd also like to remind everyone that this ticket, even if it doesn't pass its own testsuite on some dead arch, fixes actual issues with modern CPUs as reported on the mailinglist.
You mean the (reproducible) segfaults on some AVX CPUs? These can be solved by reinstalling the ATLAS spkg (one or two times)  which doesn't take that long, as these CPUs are fast... ;)
No, seriously, as a temporary "solution", we could at least put the old ATLAS, BLAS and LAPACK spkgs into the experimental branch, such that (e.g.) Itanium users can still access them (to be installed manually with ./sage f ...
of course).
W.r.t. the "dead archictecture": It's IMHO always good to test on a broad range of platforms, as that might expose real bugs that just incidentally don't show up on the "mainstream" (Intel, AMD, meanwhile perhaps also ARM); if one day GCC does no longer support Itanium, the situation will be different.
comment:137 in reply to: ↑ 134 Changed 10 years ago by
Replying to vbraun:
Replying to dimpase:
Can't one use the current ATLAS spkg on Itaniums instead of the new one? Or there are incompatibility problems?
We can use a preinstalled ATLAS library on the buildbots. Given that this is by far the slowest part of the compile cycle, I think thats reasonable.
Therefore I was suggesting to also install some script to easily "save" the ATLAS libs somewhere for later use with SAGE_ATLAS_LIB
(orthogonal to the static libraries issue).
comment:138 in reply to: ↑ 130 Changed 10 years ago by
Replying to leif:
Replying to jhpalmieri:
On skynet machine iras:
real 2251m2.189s user 2175m58.212s sys 16m29.112sOuch. How long did 3.8.4 take to build, and did you suspend the ECM background jobs? (They're back again...)
real 61m42.034s user 52m55.672s sys 1m54.940s
When compiling the new ATLAS spkg, I suspended two of the background processes (that is, I did touch /tmp/iras1
and touch /tmp/iras2
). When compiling the previous version, I didn't bother to do this.
Replying to vbraun:
I'd also like to remind everyone that this ticket, even if it doesn't pass its own testsuite on some dead arch, fixes actual issues with modern CPUs as reported on the mailinglist.
I don't feel too strongly about it either way, but I would be a little surprised if Jeroen is willing to merge this if it takes so long to build on iras.
comment:139 Changed 10 years ago by
Thats quite a speedup. I guess in your earlier test ATLAS failed to use the SAGE_ATLAS_ARCH=fast
build because of system load (first attempt), then tried SAGE_ATLAS_ARCH=base
which is the old Itanium (not Itanium 2), which then did a full search for timings. Something like that must have happened, the compile is not just 30x faster without background jobs running.
So I guess all problems are solved?
comment:140 Changed 10 years ago by
Ah, no, I think you misunderstand: it's quite a slowdown. The shorter time (~1 hour) is for 3.8.4 without suspending background processes, the longer time (~37 hours) is for 3.10.0 with two background processes suspended.
comment:141 Changed 10 years ago by
I'm going to test this on the buildbot soon, that should give more information.
comment:142 Changed 10 years ago by
This causes a build failure for cvxopt
on OS X 10.4 PPC:
running build_ext building 'gsl' extension creating build/temp.macosx10.4ppc2.7 creating build/temp.macosx10.4ppc2.7/C gcc fnostrictaliasing fwrapv DNDEBUG g fwrapv O3 Wall Wstrictprototypes I/Users/buildbot/build/sage/moufang1/moufang_full/build/sage5.3.beta3/local/include I/Users/buildbot/build/sage/moufang1/moufang_full/build/sage5.3.beta3/local/include/python2.7 c C/gsl.c o build/temp.macosx10.4ppc2.7/C/gsl.o C/gsl.c: In function 'initgsl': C/gsl.c:198:13: warning: variable 'm' set but not used [Wunusedbutsetvariable] gcc bundle undefined dynamic_lookup L/Users/buildbot/build/sage/moufang1/moufang_full/build/sage5.3.beta3/local/lib build/temp.macosx10.4ppc2.7/C/gsl.o L/Users/buildbot/build/sage/moufang1/moufang_full/build/sage5.3.beta3/local/lib L/Users/buildbot/build/sage/moufang1/moufang_full/build/sage5.3.beta3/local/lib lm lgsl lblas lgfortran lm o build/lib.macosx10.4ppc2.7/cvxopt/gsl.so /usr/bin/ld: can't locate file for: lblas collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1
comment:143 Changed 10 years ago by
 Status changed from needs_review to needs_work
Also, ATLAS failed to build on various Buildbot systems: arando (Linux i386), lena (Linux x86_64), cicero (Linux i386), iras (Linux ia64), hawk (OpenSolaris? i386).
I just tried the build once, I will retry them. But in any case, the build is more flaky than the previous version of ATLAS.
comment:144 followup: ↓ 167 Changed 10 years ago by
 Cc kcrisman added
The OSX 10.4 issue is a cvxopt bug. Where is BLAS in the ancient vecLib and why didn't Apple call it libblas? In any case I don't have access to a museum Mac, so somebody else will have to figure that out.
comment:145 Changed 10 years ago by
Technically if we want to use atlas on OS X a number of spkg including cvxopt needs to be updated. I am not sure I would call it a cvxopt bug because that's part of the configuration we introduced in spkginstall. Before the inclusion of this spkg cvxopt probably would have picked up libblas from the blas spkg. We can fix this in cvxopt of course.
comment:146 Changed 10 years ago by
I have had no problems building this on hawk (see /export/home/palmieri/testing/ATLAS/sage5.3.beta2
). On iras, as I said above, it built, but it took a long time. I haven't tried the others that you mentioned.
comment:147 Changed 10 years ago by
More buildbot results:
First attempt failed for arando (Linux i386), lena (Linux x86_64), flavius (Linux x86_64), cicero (Linux i386), iras (Linux ia64), hawk (OpenSolaris i386).
Second attempt failed for arando (Linux i386), flavius (Linux x86_64), cicero (Linux i386), iras (Linux ia64), hawk (OpenSolaris i386).
comment:148 Changed 10 years ago by
On the first try, this built successfully for me on iras, lena, and hawk. (I've built it at least twice on iras and hawk, with no failures.) On the other hand, cicero (Linux x86) and flavius (Linux x86_64) both fail to build, with essentially the same error. Log file here. They also both took a long time (about 17 hours for cicero) trying to build the ATLAS spkg. I think we need some new different settings, because the build times for cicero, flavius (almost 19 hours), and iras (34.5 hours this time) are way too long.
comment:149 followup: ↓ 152 Changed 10 years ago by
Oh I see, cicero/flavius have only a single CPU core. Talking about a blast from the past! In that case ATLAS doesn't build threaded static libraries, so we can't build threaded shared libraries. They are also so old that ATLAS can't figure out whether CPU throttling is enabled, so the full timings are collected instead of immediately falling back to a predefined archdef. Instead of trying to catch this in the ATLAS spkg and potentially not running the tuning in cases where we ought to, I think we should just configure the buildbot to set SAGE_ATLAS_ARCH=base
on these ancient machines.
comment:150 Changed 10 years ago by
I thought one of the purposes of the buildbot was to test that Sage builds "out of the box" on a variety of platforms, so tuning environment variables for use with the buildbot machines doesn't seem like the right solution. But maybe I'm not thinking about the buildbot the right way.
Also, supporting "ancient" machines is important: if we want mathematicians in underdeveloped countries, for example, to be able to use Sage, they may not have access to anything better.
comment:151 Changed 10 years ago by
Well nobody stops you from tuning ATLAS for a day if you have an ancient computer. Its just annoying on the buildbot if you want to test something else than the ATLAS build. I guess the question is: Do we want, by default, to build a stateoftheart BLAS library on all computers or only on sufficiently modern ones?
comment:152 in reply to: ↑ 149 ; followups: ↓ 153 ↓ 154 ↓ 159 Changed 10 years ago by
Replying to vbraun:
Oh I see, cicero/flavius have only a single CPU core. Talking about a blast from the past! In that case ATLAS doesn't build threaded static libraries, so we can't build threaded shared libraries.
Is that a bug in ATLAS or a bug in spkginstall
? The version of ATLAS currently in Sage doesn't have this problem.
And I'm with John on trying the build "out of the box" on the buildbots as much as possible. And I don't consider singlecore machines ancient.
comment:153 in reply to: ↑ 152 Changed 10 years ago by
Replying to jdemeyer:
And I'm with John on trying the build "out of the box" on the buildbots as much as possible.
well, 37 hours for a single package sounds like buildbot abuse. And I think that the default for slow machines with a single CPUs should be a basic Atlas install, with as little tuning as possible. There should be however be good documentation available on how to improve Atlas performance on a host, by rebuilding the spkg.
And I don't consider singlecore machines ancient.
One way or another, singlecore machines do not need many features of the new Atlas. Perhaps it's time to think about versioning possibilities: a metapackage Atlas that installs an appropriate for the architecture version?
comment:154 in reply to: ↑ 152 ; followup: ↓ 157 Changed 10 years ago by
Replying to jdemeyer:
And I'm with John on trying the build "out of the box" on the buildbots as much as possible.
So if you are fine with waiting 2 days for the slower buildbots to complete then that settles it.
comment:155 Changed 10 years ago by
Is there some sort of preliminary testing which could be done in spkginstall to try to catch machines which might take many hours to build ATLAS? For those machines, we could set the appropriate environment variable to skip as much tuning as possible, and then for quicker machines, we do more tuning. Something like
if [ z "$SAGE_ATLAS_ARCH" && machine_is_too_old ]; then SAGE_ATLAS_ARCH='skip tuning' # or whatever fi
(For 'machine_is_too_old', maybe just seeing if it only has one core would be enough.) Then the user can force tuning by setting SAGE_ATLAS_ARCH to something appropriate. I'm not sure this the the right variable, but anyway, I hope you understand the idea. Is this workable?
comment:156 Changed 10 years ago by
The old machines are slow because they are old and because there are no uptodate architectural defaults for ancient hardware. None of this can be fixed by a magic environment variable (except pointing SAGE_ATLAS_LIB
to the system atlas libraries). Basically, you can't skip tuning sparc just because you have i386 archdefs. There is a lot of assembler code that will be unhappy.
Also, I don't think there is an easy way to know that atlas would take a long time without actually building it. We could just install a reference blas on all nonstarteoftheart machines (say, less than 4 cores and 2GHz). But this will be a major rewrite of how Sage builds its BLAS libraries.
comment:157 in reply to: ↑ 154 Changed 10 years ago by
Replying to vbraun:
So if you are fine with waiting 2 days for the slower buildbots to complete then that settles it.
It doesn't quite settle it, because the new spkg simply fails to build on some machines.
comment:158 Changed 10 years ago by
I know, and I will make sure it builds on those machines. What I can't do is make ATLAS build fast on ancient hardware.
comment:159 in reply to: ↑ 152 Changed 10 years ago by
I would like to know the answer to this question: do what extent are these issues upstream issues or issues with Sage? Because the current ATLAS3.8.4 works fine.
Replying to jdemeyer:
Replying to vbraun:
Oh I see, cicero/flavius have only a single CPU core. Talking about a blast from the past! In that case ATLAS doesn't build threaded static libraries, so we can't build threaded shared libraries.
Is that a bug in ATLAS or a bug in
spkginstall
? The version of ATLAS currently in Sage doesn't have this problem.
comment:160 Changed 10 years ago by
The current ATLAS does not work fine for some modern CPUs (search the mailinglist for reports), nor does it have AVX support. Realistically, if you want to have a fast BLAS then you need to track upstream pretty closely since a lot of linear algebra performance boils down to having a good (asm) implementation tuned to your particular hardware.
The build failures that I have seen logs for were just bugs in the Sage buildscript that I'm working on fixing.
comment:161 Changed 10 years ago by
The updated spkg fixes the issue with singlecore processors. Builds fine on cicero.
comment:162 Changed 10 years ago by
Builds on cicero and flavius. On mark (Solaris), I see a problem building scipy. Could this be related? Log here.
Edit: more info, from the numpy log:
atlas_threads_info: Setting PTATLAS=ATLAS libraries lapack_atlas not found in /home/palmieri/mark/sage5.3.beta1ATLAS/local/lib numpy.distutils.system_info.atlas_threads_info Setting PTATLAS=ATLAS /home/palmieri/mark/sage5.3.beta1ATLAS/spkg/build/numpy1.5.1.p1/src/numpy/distutils/system_info.py:1010: UserWarning: ********************************************************************* Lapack library (from ATLAS) is probably incomplete: size of /home/palmieri/mark/sage5.3.beta1ATLAS/local/lib/liblapack.so is 360k (expected >4000k) Follow the instructions in the KNOWN PROBLEMS section of the file numpy/INSTALL.txt. *********************************************************************
If you have an account on skynet, feel free to look around /home/palmieri/mark/sage5.3.beta1ATLAS/
.
comment:163 followup: ↓ 165 Changed 10 years ago by
Yes totally ATLAS related. May you could also post ATLAS's log or at least the end bit of it where it builds lapack.
comment:164 Changed 10 years ago by
I've added archdefs for Itanium2, now build time is a lot faster:
vbraun@iras:~/opt/iras/sage5.3.beta0> SAGE_ATLAS_ARCH=fast ./sage f http://www.stp.dias.ie/~vbraun/Sage/spkg/atlas3.10.0.spkg [...] real 44m44.170s user 41m47.156s sys 2m42.456s
Though if you don't specify SAGE_ATLAS_ARCH
it will still run, by default, a full tuning. If that fails for any reason it will try SAGE_ATLAS_ARCH=fast
next.
comment:165 in reply to: ↑ 163 Changed 10 years ago by
comment:166 Changed 10 years ago by
I am not sure what happens at all. I am not convinced that the original lapack archive is getting relinked along with the C interface from ATLAS but that's not easy to establish from the log because of the size. I would need to spend some time looking at it carefully.
comment:167 in reply to: ↑ 144 ; followup: ↓ 168 Changed 10 years ago by
The OSX 10.4 issue is a cvxopt bug. Where is BLAS in the ancient vecLib and why didn't Apple call it libblas? In any case I don't have access to a museum Mac, so somebody else will have to figure that out.
Reporting for duty! Currently building MPIR, with with changes in this ticket (except the doctest/doc patch, which is no biggie).
Would this issue only come up if someone did set SAGE_ATLAS_ARCH=base
or at any rate set it? I though that using the system ATLAS was still the default on Mac after this ticket  was that a misunderstanding? I might find out before I leave work today... but if it doesn't break without resetting that variable, I don't think that is as bad, since hopefully no one using this old of a machine is depending on it for fast linear algebra.
comment:168 in reply to: ↑ 167 Changed 10 years ago by
Replying to kcrisman:
The OSX 10.4 issue is a cvxopt bug. Where is BLAS in the ancient vecLib and why didn't Apple call it libblas? In any case I don't have access to a museum Mac, so somebody else will have to figure that out.
Reporting for duty! Currently building MPIR, with with changes in this ticket (except the doctest/doc patch, which is no biggie).
Would this issue only come up if someone did set
SAGE_ATLAS_ARCH=base
or at any rate set it? I though that using the system ATLAS was still the default on Mac after this ticket  was that a misunderstanding? I might find out before I leave work today... but if it doesn't break without resetting that variable, I don't think that is as bad, since hopefully no one using this old of a machine is depending on it for fast linear algebra.
That would be a start but most of the spkg using blas have specific rules for OS X and we would need to change them before they start using ATLAS instead of veclib. From the top of my head:
 iml (actually that would solve some problems)
 linbox
 numpy
 scipy
 cvxopt
 R?
I believe sage itself can cope with the change as is but it should be checked.
comment:169 Changed 10 years ago by
My point was not that we should switch to ATLAS, but rather that it might be possible to have a different ticket for making ATLAS work optionally on Mac this way, if Sage builds and tests fine with this new ATLAS in the case where Mac does not actually build it. I don't know if that's true, though, since jdemeyer's report could perhaps have been with that env var set.
comment:170 Changed 10 years ago by
Well, it turns out that it must be removing the other spkgs that does it.
building 'gsl' extension creating build/temp.macosx10.4ppc2.7 creating build/temp.macosx10.4ppc2.7/C gcc fnostrictaliasing fwrapv DNDEBUG g fwrapv O3 Wall Wstrictprototypes I/Users/student/Desktop/sage5.3.rc0/local/include I/Users/student/Desktop/sage5.3.rc0/local/include/python2.7 c C/gsl.c o build/temp.macosx10.4ppc2.7/C/gsl.o C/gsl.c: In function 'initgsl': C/gsl.c:198:13: warning: variable 'm' set but not used [Wunusedbutsetvariable] gcc bundle undefined dynamic_lookup L/Users/student/Desktop/sage5.3.rc0/local/lib build/temp.macosx10.4ppc2.7/C/gsl.o L/Users/student/Desktop/sage5.3.rc0/local/lib L/Users/student/Desktop/sage5.3.rc0/local/lib lm lgsl lblas lgfortran lm o build/lib.macosx10.4ppc2.7/cvxopt/gsl.so /usr/bin/ld: can't locate file for: lblas collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 Error building/installing cvxopt real 0m3.866s user 0m1.281s sys 0m1.359s ************************************************************************ Error installing package cvxopt1.1.5 ************************************************************************
Now I understand Volker's comment. Maybe we can just have a different configuration when using old Macs, as in François' comment. But I wouldn't know how to do that.
comment:171 Changed 10 years ago by
With SAGE_ATLAS_ARCH=base
on the same machine, I get
Base configuration on PPC. Running configure with arch = POWER4, isa extensions (), archdef dir None Running ../src/configure prefix=/Users/student/Desktop/sage5.3.rc0/local withnetliblapacktarfile=/Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/lapack3.4.1.tgz cc="gcc" Si latune 0 Fa alg fPIC C if "/Users/student/Desktop/sage5.3.rc0/local/bin/sage_fortran" C acg "/Users/student/Desktop/sage5.3.rc0/local/bin/gcc" b 32 O 12 A 2 V 0 gcc I/Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild/../src//CONFIG/include g w c /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild/../src//CONFIG/src/atlconf_misc.c gcc I/Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild/../src//CONFIG/include g w o xconfig /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild/../src//CONFIG/src/config.c atlconf_misc.o ./xconfig d s /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild/../src/ d b /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild Si lapackref 1 Si latune 0 Fa alg fPIC C if /Users/student/Desktop/sage5.3.rc0/local/bin/sage_fortran C acg /Users/student/Desktop/sage5.3.rc0/local/bin/gcc b 32 O 12 A 2 V 0 gcc I/Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild/../src//CONFIG/include g w o xisgcc /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild/../src//CONFIG/src/IsGcc.c atlconf_misc.o gcc I/Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild/../src//CONFIG/include g w c /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild/../src//CONFIG/src/probe_comp.c gcc I/Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild/../src//CONFIG/include g w o xprobe_comp probe_comp.o atlconf_misc.o rm f config1.out make j1 atlas_run atldir=/Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild exe=xprobe_comp redir=config1.out \ args="v 0 o atlconf.txt O 12 A 2 Si nof77 0 V 0 C ic '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa ic 'fPIC' C sm '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa sm 'fPIC' C dm '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa dm 'fPIC' C sk '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa sk 'fPIC' C dk '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa dk 'fPIC' C xc '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa xc 'fPIC' C gc '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa gc 'fPIC' C if '/Users/student/Desktop/sage5.3.rc0/local/bin/sage_fortran' Fa if 'fPIC' b 32 d b /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild" cd /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild ; ./xprobe_comp v 0 o atlconf.txt O 12 A 2 Si nof77 0 V 0 C ic '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa ic 'fPIC' C sm '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa sm 'fPIC' C dm '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa dm 'fPIC' C sk '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa sk 'fPIC' C dk '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa dk 'fPIC' C xc '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa xc 'fPIC' C gc '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa gc 'fPIC' C if '/Users/student/Desktop/sage5.3.rc0/local/bin/sage_fortran' Fa if 'fPIC' b 32 d b /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/ATLASbuild > config1.out /bin/sh: line 1: ./xctest: Bad CPU type in executable make[5]: *** [atlas_run] Error 126 make[4]: *** [IRunCComp] Error 2 Unable to find usable compiler for ICC; abortingMake sure compilers are in your path, and specify good compilers to configure (see INSTALL.txt or 'configure help' for details)make[3]: *** [atlas_run] Error 1 make[2]: *** [IRun_comp] Error 2 ERROR 512 IN SYSCMND: 'make IRun_comp args="v 0 o atlconf.txt O 12 A 2 Si nof77 0 V 0 C ic '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa ic 'fPIC' C sm '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa sm 'fPIC' C dm '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa dm 'fPIC' C sk '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa sk 'fPIC' C dk '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa dk 'fPIC' C xc '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa xc 'fPIC' C gc '/Users/student/Desktop/sage5.3.rc0/local/bin/gcc' Fa gc 'fPIC' C if '/Users/student/Desktop/sage5.3.rc0/local/bin/sage_fortran' Fa if 'fPIC' b 32"' Assembly configured as GAS_PPC (4) Bad VECFLAG value=0, res='VECFLAG=0 ' Vector ISA Extension configured as (0,0) Clock rate configured as 700Mhz Maximum number of threads configured as 1 Cannot detect CPU throttling. mkdir src bin tune interfaces cd src ; mkdir testing auxil blas lapack pthreads threads cd src/blas ; \ mkdir f77reference reference gemv ger gemm kbmm \ level1 level2 level3 pklevel3 cd src/blas/reference ; mkdir level1 level2 level3 cd src/blas/level2 ; mkdir kernel cd src/blas/pklevel3 ; mkdir gpmm sprk cd src/blas/level3 ; mkdir rblas kernel cd src/pthreads ; mkdir blas misc cd src/pthreads/blas ; mkdir level1 level2 level3 cd src/threads ; mkdir blas lapack cd src/threads/blas ; mkdir level3 level2 cd tune ; mkdir blas sysinfo lapack threads cd tune/blas ; mkdir gemm gemv ger level1 level3 cd interfaces ; mkdir blas lapack cd interfaces/lapack ; mkdir C F77 cd interfaces/lapack/C ; mkdir src testing cd interfaces/lapack/F77 ; mkdir src testing cd interfaces/blas ; mkdir C F77 cd interfaces/blas/C ; mkdir src testing cd interfaces/blas/F77 ; mkdir src testing cd interfaces/lapack ; mkdir C2F cd interfaces/lapack/C2F ; mkdir src mkdir ARCHS make j1 f Make.top startup Make.top:1: Make.inc: No such file or directory Make.top:325: warning: overriding commands for target `/AtlasTest' Make.top:76: warning: ignoring old commands for target `/AtlasTest' make[3]: *** No rule to make target `Make.inc'. Stop. make[2]: *** [startup] Error 2 mv: rename lib/Makefile to lib/Make.tmp: No such file or directory ../src/configure: line 450: lib/Makefile: No such file or directory ../src/configure: line 451: lib/Makefile: No such file or directory ../src/configure: line 452: lib/Makefile: No such file or directory ../src/configure: line 453: lib/Makefile: No such file or directory ../src/configure: line 509: lib/Makefile: No such file or directory DONE configure Finished configuring ATLAS. Running make j1 make j1 f Make.top build Make.top:1: Make.inc: No such file or directory Make.top:325: warning: overriding commands for target `/AtlasTest' Make.top:76: warning: ignoring old commands for target `/AtlasTest' make[3]: *** No rule to make target `Make.inc'. Stop. make[2]: *** [build] Error 2  File "./spkginstall", line 476, in <module> assert_success(rc, bad='Failed to build ATLAS.', good='Finished building ATLAS core.') File "./spkginstall", line 76, in assert_success traceback.print_stack(file=sys.stdout)  Error: Failed to build ATLAS. real 1m2.106s user 0m15.388s sys 0m25.736s ************************************************************************ Error installing package atlas3.10.0 ************************************************************************
comment:172 Changed 10 years ago by
Oh I take it your museum piece doesn't have a Power4 CPU. Can you try
SAGE_ATLAS_ARCH=PPCG4 sage f http://www.stp.dias.ie/~vbraun/Sage/spkg/atlas3.10.0.spkg
comment:173 Changed 10 years ago by
Correct, PowerPC G4, which I think is slightly different. It's currently compiling fine, I'll let you know the results.
In other news, #13408 seems to be a dup of this ticket. I don't know if we support "rhel 5" systems currently, nor whether this particular spkg fixes that person's problem, though.
comment:174 Changed 10 years ago by
Finished installing shared ATLAS library. Copying /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0/patches/atlasconfig to /Users/student/Desktop/sage5.3.rc0/local/bin real 1558m23.512s user 1148m7.019s sys 243m20.134s Successfully installed atlas3.10.0 Deleting temporary build directory /Users/student/Desktop/sage5.3.rc0/spkg/build/atlas3.10.0 Making Python scripts relocatable... Finished installing atlas3.10.0.spkg
Good as far as it goes! Is this the record for longest ATLAS build ever?
Typing make
after that still leads to the cvxopt can't find file for lblas
error; can someone remind me what the command would be to force rebuilding of dependencies (if that would even make a difference)?
comment:175 Changed 10 years ago by
So all we have to do is build ATLAS on OSX 10.4, then we don't have to figure out how to drive the ancient accelerate framework. Dima, can you change cvxopt to link against atlas on 10.4?
comment:176 Changed 10 years ago by
I see, so that's why the problem is the same. Sounds like either we would do this, or fbissey's idea of a different configuration now.
I've touched cvxopt and am trying to build the rest of Sage now, so don't hold your breath yet that this was a permanent fix (in addition to roughly doubling the build time of Sage, not that this would matter on this platform).
comment:177 Changed 10 years ago by
I've changed the spkg to build by default on PPC OSX machines (Darwin + uname p
equals powerpc
).
comment:178 Changed 10 years ago by
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 bytecompiling package 'graphics' Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared object '/Users/student/Desktop/sage5.3.rc0/spkg/build/r2.14.0.p3/src/library/grDevices/libs/grDevices.so': dlopen(/Users/student/Desktop/sage5.3.rc0/spkg/build/r2.14.0.p3/src/library/grDevices/libs/grDevices.so, 6): Symbol not found: _ATL_DecAtomicCount Referenced from: /Users/student/Desktop/sage5.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 r2.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.
comment:179 Changed 10 years ago by
Haha, I was wrong. Same error in Scipy:
23, in <module> from numpy.linalg import lapack_lite ImportError: dlopen(/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/lapack_lite.so, 2): Symbol not found: _ATL_DecAtomicCount Referenced from: /Users/student/Desktop/sage5.3.rc0/local/lib/libatlas.2.dylib Expected in: dynamic lookup Error building scipy. real 0m3.779s user 0m0.437s sys 0m0.840s ************************************************************************ Error installing package scipy0.9.p1 ************************************************************************
comment:180 Changed 10 years ago by
And finally:
spkg/pipestatus "./sage docbuild nopdflinks all html 2>&1" "tee a dochtml.log" Warning: Could not import sage.calculus.riemann dlopen(/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/lapack_lite.so, 2): Symbol not found: _ATL_DecAtomicCount Referenced from: /Users/student/Desktop/sage5.3.rc0/local/lib/libatlas.2.dylib Expected in: dynamic lookup Traceback (most recent call last): File "/Users/student/Desktop/sage5.3.rc0/devel/sage/doc/common/builder.py", line 1098, in <module> getattr(get_builder(name), type)() File "/Users/student/Desktop/sage5.3.rc0/devel/sage/doc/common/builder.py", line 243, in _wrapper getattr(get_builder(document), name)(*args, **kwds) File "/Users/student/Desktop/sage5.3.rc0/devel/sage/doc/common/builder.py", line 363, in _wrapper self.write_auto_rest_file(module_name) File "/Users/student/Desktop/sage5.3.rc0/devel/sage/doc/common/builder.py", line 622, in write_auto_rest_file title = self.get_module_docstring_title(module_name) File "/Users/student/Desktop/sage5.3.rc0/devel/sage/doc/common/builder.py", line 580, in get_module_docstring_title __import__(module_name) File "numpy.pxd", line 154, in init sage.calculus.interpolators (sage/calculus/interpolators.c:5716) File "/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/__init__.py", line 136, in <module> import add_newdocs File "/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/add_newdocs.py", line 9, in <module> from numpy.lib import add_newdoc File "/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/__init__.py", line 13, in <module> from polynomial import * File "/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/polynomial.py", line 11, in <module> import numpy.core.numeric as NX AttributeError: 'module' object has no attribute 'core' make: *** [dochtml] Error 1
so it won't even build doc, which is weird, since it did say that Sage started properly.
comment:181 Changed 10 years ago by
The last two errors are really a misconfiguration/miscompilation of numpy. If you look at /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/lapack_lite.so with otool L (I think) you may see something. In fact the deeper problem seem to be that the dynamic lookup doesn't find libatlas.dylib. I am not sure if explicit linking would solve the problem. We should look at the numpy spkg and also atyour numpy log to see how lapack_lite.so was linked.
comment:182 Changed 10 years ago by
:~/Desktop/sage5.3.rc0 student$ otool L local/lib/python2.7/sitepackages/numpy/linalg/lapack_lite.so local/lib/python2.7/sitepackages/numpy/linalg/lapack_lite.so: /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /Users/student/Desktop/sage5.3.rc0/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)
I've uploaded the log to http://sage.math.washington.edu/home/kcrisman/numpy1.5.1.p1.log as well. What do you think the R problem is?
comment:183 Changed 10 years ago by
For R it looks like a similar problem. R uses lapack and compile its own subset if not present. It also looks for ATLAS specific bits. Did you run otool from the sage shell? In this case I don't think it matters but you should look at those library problem from a sage shell to get the right LD_LIBRARY_PATH settings.
comment:184 Changed 10 years ago by
$ otool L local/lib/python2.7/sitepack ages/numpy/linalg/lapack_lite.so local/lib/python2.7/sitepackages/numpy/linalg/lapack_lite.so: /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /Users/student/Desktop/sage5.3.rc0/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)
comment:185 Changed 10 years ago by
OK that's weird. According to your log of building numpy, lapack_lite.so was compiled against veclib rather than atlas and this is in accord with your otool output. So the problem may steem from a relinking or hiding of the veclib library by atlas. It is probably finding the symbols in the ATLAS install first. The problem in turn seems to be that libatlas.2.dylib is missing a symbol or that it should be provided by an extra library not provided. otool L r on libatlas.2.dylib? (I hope the r does what I except: same thing as r in ldd in linux), actually on lapack_lite.so while you are at it.
comment:186 Changed 10 years ago by
I'm not sure that was what you wanted.
$ otool L r local/lib/libatlas.dylib local/lib/libatlas.dylib: /Users/student/Desktop/sage5.3.rc0/local/lib/libatlas.2.dylib (compatibility version 4.0.0, current version 4.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /Users/student/Desktop/sage5.3.rc0/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12) External relocation information 0 entries address pcrel length extern type scattered symbolnum/value Local relocation information 1107 entries address pcrel length extern type scattered symbolnum/value 005a7000 0 2 0 0 0 1 005a7c4c 0 2 0 0 0 1 005a7c48 0 2 0 0 0 1 005a7c44 0 2 0 0 0 1
This continues for a long, long while.
comment:187 Changed 10 years ago by
It's not. I am not sure there is an otool equivalent for "ldd r". Another point: from the error you get I am expecting that if you start python from the sage shell and then "import numpy" if will fail with a similar error. Starting python with "v" may show us what libraries get loaded exactly when you import numpy.
comment:188 Changed 10 years ago by
According to the man page for ldd, that option only works on ELF binaries (whatever that means), and this blog post confirms that Mac doesn't use them. This other blog post suggests that dyld might be useful...
Numpy results coming up.
comment:189 Changed 10 years ago by
Same symbol not found, all the way at the end. If this is too long let me know and I'll edit (!) this comment.
>>> import numpy import numpy # directory /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/__init__.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/__init__.py import numpy # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/__init__.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/__config__.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/__config__.py import numpy.__config__ # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/__config__.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/version.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/version.py import numpy.version # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/version.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/_import_tools.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/_import_tools.py import numpy._import_tools # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/_import_tools.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/add_newdocs.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/add_newdocs.py import numpy.add_newdocs # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/add_newdocs.pyc import numpy.lib # directory /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/__init__.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/__init__.py import numpy.lib # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/__init__.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/info.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/info.py import numpy.lib.info # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/info.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/type_check.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/type_check.py import numpy.lib.type_check # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/type_check.pyc import numpy.core # directory /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/__init__.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/__init__.py import numpy.core # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/__init__.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/info.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/info.py import numpy.core.info # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/info.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/multiarray.so", 2); import numpy.core.multiarray # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/multiarray.so dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/umath.so", 2); import numpy.core.umath # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/umath.so # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/_internal.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/_internal.py import numpy.core._internal # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/_internal.pyc import numpy.compat # directory /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/compat # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/compat/__init__.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/compat/__init__.py import numpy.compat # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/compat/__init__.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/compat/_inspect.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/compat/_inspect.py import numpy.compat._inspect # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/compat/_inspect.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/compat/py3k.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/compat/py3k.py import numpy.compat.py3k # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/compat/py3k.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/numerictypes.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/numerictypes.py import numpy.core.numerictypes # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/numerictypes.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/_sort.so", 2); import numpy.core._sort # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/_sort.so # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/numeric.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/numeric.py import numpy.core.numeric # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/numeric.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/_dotblas.so", 2); # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/arrayprint.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/arrayprint.py import numpy.core.arrayprint # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/arrayprint.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/fromnumeric.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/fromnumeric.py import numpy.core.fromnumeric # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/fromnumeric.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/cPickle.so", 2); dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/cStringIO.so", 2); import cStringIO # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/cStringIO.so import cPickle # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/cPickle.so # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/defchararray.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/defchararray.py import numpy.core.defchararray # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/defchararray.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/records.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/records.py import numpy.core.records # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/records.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/memmap.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/memmap.py import numpy.core.memmap # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/memmap.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/scalarmath.so", 2); import numpy.core.scalarmath # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/scalarmath.so # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/function_base.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/function_base.py import numpy.core.function_base # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/function_base.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/machar.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/machar.py import numpy.core.machar # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/machar.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/getlimits.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/getlimits.py import numpy.core.getlimits # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/getlimits.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/shape_base.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/shape_base.py import numpy.core.shape_base # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/core/shape_base.pyc import numpy.testing # directory /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/__init__.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/__init__.py import numpy.testing # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/__init__.pyc import unittest # directory /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest # /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/__init__.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/__init__.py import unittest # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/__init__.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/result.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/result.py import unittest.result # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/result.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/StringIO.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/StringIO.py import StringIO # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/StringIO.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/util.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/util.py import unittest.util # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/util.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/collections.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/collections.py import collections # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/collections.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/_collections.so", 2); import _collections # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/_collections.so dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/operator.so", 2); import operator # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/operator.so # /Users/student/Desktop/sage5.3.rc0/local/lib/python/keyword.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/keyword.py import keyword # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/keyword.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/heapq.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/heapq.py import heapq # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/heapq.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/itertools.so", 2); import itertools # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/itertools.so # /Users/student/Desktop/sage5.3.rc0/local/lib/python/bisect.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/bisect.py import bisect # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/bisect.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/_bisect.so", 2); import _bisect # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/_bisect.so dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/_heapq.so", 2); import _heapq # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/_heapq.so import thread # builtin # /Users/student/Desktop/sage5.3.rc0/local/lib/python/functools.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/functools.py import functools # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/functools.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/_functools.so", 2); import _functools # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/_functools.so # /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/case.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/case.py import unittest.case # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/case.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/difflib.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/difflib.py import difflib # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/difflib.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/pprint.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/pprint.py import pprint # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/pprint.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/suite.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/suite.py import unittest.suite # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/suite.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/loader.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/loader.py import unittest.loader # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/loader.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/fnmatch.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/fnmatch.py import fnmatch # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/fnmatch.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/main.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/main.py import unittest.main # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/main.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/runner.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/runner.py import unittest.runner # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/runner.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/time.so", 2); import time # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/time.so # /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/signals.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/signals.py import unittest.signals # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/unittest/signals.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python/weakref.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python/weakref.py import weakref # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python/weakref.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/decorators.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/decorators.py import numpy.testing.decorators # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/decorators.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/utils.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/utils.py import numpy.testing.utils # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/utils.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/nosetester.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/nosetester.py import numpy.testing.nosetester # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/nosetester.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/numpytest.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/numpytest.py import numpy.testing.numpytest # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/testing/numpytest.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/ufunclike.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/ufunclike.py import numpy.lib.ufunclike # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/ufunclike.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/index_tricks.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/index_tricks.py import numpy.lib.index_tricks # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/index_tricks.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/math.so", 2); import math # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/libdynload/math.so # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/function_base.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/function_base.py import numpy.lib.function_base # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/function_base.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/twodim_base.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/twodim_base.py import numpy.lib.twodim_base # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/twodim_base.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/_compiled_base.so", 2); import numpy.lib._compiled_base # dynamically loaded from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/_compiled_base.so # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/arraysetops.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/arraysetops.py import numpy.lib.arraysetops # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/arraysetops.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/utils.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/utils.py import numpy.lib.utils # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/utils.pyc import numpy.matrixlib # directory /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/matrixlib # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/matrixlib/__init__.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/matrixlib/__init__.py import numpy.matrixlib # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/matrixlib/__init__.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/matrixlib/defmatrix.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/matrixlib/defmatrix.py import numpy.matrixlib.defmatrix # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/matrixlib/defmatrix.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/shape_base.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/shape_base.py import numpy.lib.shape_base # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/shape_base.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/stride_tricks.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/stride_tricks.py import numpy.lib.stride_tricks # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/stride_tricks.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/scimath.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/scimath.py import numpy.lib.scimath # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/scimath.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/polynomial.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/polynomial.py import numpy.lib.polynomial # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/polynomial.pyc import numpy.linalg # directory /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/__init__.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/__init__.py import numpy.linalg # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/__init__.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/info.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/info.py import numpy.linalg.info # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/info.pyc # /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/linalg.pyc matches /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/linalg.py import numpy.linalg.linalg # precompiled from /Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/linalg.pyc dlopen("/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/lapack_lite.so", 2); Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/__init__.py", line 136, in <module> import add_newdocs File "/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/add_newdocs.py", line 9, in <module> from numpy.lib import add_newdoc File "/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/__init__.py", line 13, in <module> from polynomial import * File "/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/lib/polynomial.py", line 17, in <module> from numpy.linalg import eigvals, lstsq File "/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/__init__.py", line 48, in <module> from linalg import * File "/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/linalg.py", line 23, in <module> from numpy.linalg import lapack_lite ImportError: dlopen(/Users/student/Desktop/sage5.3.rc0/local/lib/python2.7/sitepackages/numpy/linalg/lapack_lite.so, 2): Symbol not found: _ATL_DecAtomicCount Referenced from: /Users/student/Desktop/sage5.3.rc0/local/lib/libatlas.2.dylib Expected in: dynamic lookup
comment:190 Changed 10 years ago by
Hi,
now that I reread the comments here again, I seem to faintly remember this problem circle from my adventure with lmonade (Gentoo Prefix derivative) on OS X 10.4 last year. See my travel account about this, points "22." and "26." and especially the rant following that in:
https://groups.google.com/d/msg/lmnddevel/1ZqHx1JBY2Q/syAOZYtZN4IJ
 If my memory is correct, the symbol "_ATL_DecAtomicCount" comes from/is resolved in libblas(.dylib), this could be checked independently from the underlying OS. Where is libblas.dylib (libblas.so under Linux) located, is it something like .../lib/blas/reference/?
 KarlDieter, I try to catch up with what you installed and tried, but till then could you please try
"sage R"
anyway in the meantime (from the shell prompt) and print the result, probably an error message from the OS X 10.4 lessthanoptimal dyld dynamic loader?
 If this really is what the problem is about, some symlinks might suffice, but I do not remember exactly how and for which libraries (both R and maxima were affected in a weird way, and Volker's compilerwrapper intervenes in the lmonade setting, too).
Best regards,
Georg
P.S.: Later last year, I ultimately managed somehow to get some 64bit Sage (lmonade flavour) working on the 32bit OS X 10.4, so in the course, I definitely had to successfully build and link/reference some new "selfmade" 64bit atlas/blas, since OS X 10.4 only ships with a 32bit "system copy" of atlas/blas, so this is definitely doable. But even Python itself is not officially supported as 64bit version on OS X 10.4, so quite some more hackery was needed. (This only might be interesting, if one day the Sage project wants to get rid of the dependency of certain Apple system library headers, which come only with "XCode", or more precisely the "command line tools", on newer OS X versions  currently these are a prerequisite for building Sage on OS X.)
comment:191 Changed 10 years ago by
Yeah I remember those bits vaguely now. But lmnd never used libvec unless you hacked something (I have an ebuild to allow that but noone else has seen it). The location you mention in (1) is specific to gentoo and correspond to netlib blas (otherwise called blas reference) current lmnd uses a different scheme. A lmnd user could pick openblas or gotoblas these days.
The link idea is interesting, having $SAGE_LOCAL/lib/libblas.dylib pointing to libvec could help.
comment:192 Changed 10 years ago by
(sagesh) student@Dasher03:sage5.3.rc0$ ./sage R /Users/student/Desktop/sage5.3.rc0/spkg/bin/sage: line 496: /Users/student/Desktop/sage5.3.rc0/local/bin/R: No such file or directory
But that's expected, since I didn't succeed in building R with this.
comment:193 Changed 10 years ago by
With OS X 10.4 on my MacIntel?, I ran with sage5.3.rc1 into the same problem as earlier reported here (for Sage5.2 and Sage5.1, I can confirm the problem exists already for Sage5.1):
The fix is trivial (once one knows what the problem is), in module_list.py there is a "lpari" option missing for the cremona.mat module (for the other cremona.xxx modules, the "lpari" option is listed with a comment about "Cygiwn might need this"  obviously the dynamic linker/loader on OS X 10.4 MacIntel? is comparably dumb). Once I sorted out creating a corresponding ticket, uploaded the fix there, and answered to the thread above, I'll continue with the atlas story here.
comment:194 Changed 10 years ago by
Hi all, it is really puzzling, why with current Sage5.3 on OS X 10.4 PPC (yesterday released, it's up on the servers), the cvxopt1.1.5 spkg finds during its build the blas.dylib  but with the changes of this ticket here, cvxopt1.1.5 does not find it anymore (see comments #142 and #170 here).
Some facts:
 On OS X 10.4 PPC, under the directory "/usr/lib/", there are no "atlas.dylib", "blas.dylib", "cblas.dylib", "lapack.dylib" files or links (on OS X 10.4 Intel, these four entries *do* exist there, as links).
 On OS X 10.4 (both PPC and Intel), Sage historically does not build atlas nor blas (nor cblas) nor lapack, so there are not corresponding dylibs either under "$SAGE_ROOT/local/lib/".
 In $SAGE_ROOT/devel/sagemain/module_list.py, there is some magic for the configuration of the "BLAS" and "BLAS2" macros. Given the above fact(s), on OS X 10.4 PPC, I read these as resulting to use "gslblas" (!!) provided by Sage, on OS X 10.4 Intel, I read these as resulting to use the system "cblas" and "atlas".
 On OS X 10.4 Intel, these "system" atlas, blas, and cblas libraries actually all link to one and the same "blas.dylib" located under /System/Libraries/Frameworks/Accelerate?.framework/version/A/vecLIB.framwork/version/A/ (or some permutation thereof, I can't look up the exact path right now at the moment). These libraries are also located there under OS X 10.4 PPC, but there do not seem to be any links.
 The old cvxopt1.1.4(.p1) lists "gslblas" as library to be linked to, but actually, it is unclear at least to me, which kind of "blas" library really got used in the end on OS X 10.4  maybe on PPC some different one than on Intel.
Is it possible that currently, the build of cvxopt1.1.5 on OS X 10.4 PPC succeeds only during a "whole" build of Sagte5.3, the linker somehow caching the libraries it finds in the course of the build (especially "blas.dylib" somewhen before cvxopt is built)  and with the changes of this ticket, the build sequence changes somehow so suddenly, "blas.dylib" is not anymore in this cache (or whatever kind of mechansim with the same result)?
comment:195 followup: ↓ 196 Changed 10 years ago by
Before this ticket netlib's blas (blas spkg) would be build on OS X if I am not mistaken. So an unoptimized blas would be present to be picked in SAGE_LOCAL/lib. cblas would indeed be provided by gslblas if nothing else.
comment:196 in reply to: ↑ 195 Changed 10 years ago by
Replying to fbissey:
Before this ticket netlib's blas (blas spkg) would be build on OS X if I am not mistaken. So an unoptimized blas would be present to be picked in SAGE_LOCAL/lib. cblas would indeed be provided by gslblas if nothing else.
hmm, no, I think on OSX there is native blas/lapack (veclib) which was used (and still is used, given the right settings used to build Sage).
comment:197 followup: ↓ 198 Changed 10 years ago by
I agree with Francois, we probably never used the ancient accelerate (OSX 10.4) framework correctly. In fact, this ticket makes it pretty clear that we did not.
comment:198 in reply to: ↑ 197 ; followup: ↓ 199 Changed 10 years ago by
Replying to vbraun:
I agree with Francois, we probably never used the ancient accelerate (OSX 10.4) framework correctly. In fact, this ticket makes it pretty clear that we did not.
as far as CVXOPT is concerned, it does use MacOSX veclib (there was a OSX 10.7related ticket which dealt with the fact that veclib changed some undefined behaviour when 10.7 was released, and CVXOPT got hit by this issue).
comment:199 in reply to: ↑ 198 ; followups: ↓ 200 ↓ 207 Changed 10 years ago by
Replying to dimpase:
as far as CVXOPT is concerned, it does use MacOSX veclib
Are you sure? I think OSX 10.4 is rather different from modern OSX accelerate. Post the output of otool L
on OSX 10.4 PPC or it didn't happen ;)
comment:200 in reply to: ↑ 199 ; followup: ↓ 201 Changed 10 years ago by
Two hundred comments!
as far as CVXOPT is concerned, it does use MacOSX veclib
Are you sure? I think OSX 10.4 is rather different from modern OSX accelerate. Post the output of
otool L
on OSX 10.4 PPC or it didn't happen ;)
Tell me the exact command (otool L what_file?
) and I'll do it as soon as I get to work.
comment:201 in reply to: ↑ 200 Changed 10 years ago by
Replying to kcrisman:
Two hundred comments!
as far as CVXOPT is concerned, it does use MacOSX veclib
Are you sure? I think OSX 10.4 is rather different from modern OSX accelerate. Post the output of
otool L
on OSX 10.4 PPC or it didn't happen ;)Tell me the exact command (
otool L what_file?
) and I'll do it as soon as I get to work.
$ cd $SAGE_LOCAL/lib/python/sitepackages/cvxopt $ otool L lapack.so
comment:202 followups: ↓ 203 ↓ 205 Changed 10 years ago by
So who was right?
Dasher03:~/Desktop/sage4.8/local/lib/python/sitepackages/cvxopt student$ otool L lapack.so lapack.so: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12) /Users/student/Desktop/sage4.8/local/lib/libgsl.0.dylib (compatibility version 17.0.0, current version 17.0.0) /Users/student/Desktop/sage4.8/local/lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
This is with Sage 4.8, the last working binary I have on this box. I foolishly deleted all newer ones in the meantime. Sage 5.3 works on it, of course  in fact, I just used the app bundle yesterday  but it would take some time to start a fresh 5.3 or 5.4.beta0.
comment:203 in reply to: ↑ 202 Changed 10 years ago by
Replying to kcrisman:
So who was right?
Dasher03:~/Desktop/sage4.8/local/lib/python/sitepackages/cvxopt student$ otool L lapack.so lapack.so: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12) /Users/student/Desktop/sage4.8/local/lib/libgsl.0.dylib (compatibility version 17.0.0, current version 17.0.0) /Users/student/Desktop/sage4.8/local/lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
looks like this particular system does not use the veclib framework. Is it Intel, or PPC?
comment:204 Changed 10 years ago by
Dasher03:~/Desktop/sage4.8/local/lib/python/sitepackages/cvxopt student$ uname a Darwin Dasher03.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu792.24.17~1/RELEASE_PPC Power Macintosh powerpc
At 700 MHz and half a gig of ram, probably one of the lowestcapability machines running Sage today... but it works fine, if slow. But we're just spoiled  I'm sure Gauss or Newton would have been happy to have this :)
comment:205 in reply to: ↑ 202 Changed 10 years ago by
Replying to kcrisman:
So who was right?
Dasher03:~/Desktop/sage4.8/local/lib/python/sitepackages/cvxopt student$ otool L lapack.so lapack.so: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12) /Users/student/Desktop/sage4.8/local/lib/libgsl.0.dylib (compatibility version 17.0.0, current version 17.0.0) /Users/student/Desktop/sage4.8/local/lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)This is with Sage 4.8, the last working binary I have on this box. I foolishly deleted all newer ones in the meantime. Sage 5.3 works on it, of course  in fact, I just used the app bundle yesterday  but it would take some time to start a fresh 5.3 or 5.4.beta0.
It is not necessary to "start a fresh 5.3 or 5.4.beta0". Instead, one can go to some Sage OS X PPC download page, http://boxen.math.washington.edu/home/sagemath/sagemirror/osx/powerpc/index.html , download from there e.g. "sage5.3OSX32bit10.4PowerMacintosh?Darwin.dmg", and look inside  on any OS X system/version. The result is ... surprising, to say the least:
sagebuilder$ otool L lapack.so lapack.so: /Users/buildbot/build/sage/moufang1/moufang_binary/build/sage5.3/local/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /Users/buildbot/build/sage/moufang1/moufang_binary/build/sage5.3/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)
The two occurences of "libgcc_s.1.dylib" are somewhat fishy, but apparently nothing new, and I'd vote for that topic being a complete different story, and not to be treated here any further. The library "libSystem.B.dylib" is the C runtime on OS X, AFAIK. But then only libfortran.dylib  and no trace whatsoever of any *las.dylib?!?!? For comparison, on OS X 10.4 Intel, for Sage5.3.rc1 the analoguous result is:
sagebuilder$ otool L lapack.so lapack.so: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib (compatibility version 1.0.0, current version 192.15.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 192.15.0) /Users/Shared/sage/sage5.3.rc1/local/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /Users/Shared/sage/sage5.3.rc1/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.11)
I would conclude that it is problematic, that the OS X 10.4 PPC linker/loader builds at all the current cvxopt1.1.5 spkg contained in Sage5.3, producing results with such incomplete dependency information. Looking closely on the command line, it is told to use "undefined dynamic_lookup" (which seems to save us at runtime later, however only by chance, I guess), so essentially it does what it should  but then, why does that linker/loader under some very comparable circumstances error out with "/usr/bin/ld: can't locate file for: lblas"???
Of the different alternatives to come to an end with this ticket here (which is about the new atlas3.10 spkg), I like the "link idea" (see the comment 191 from Francois), i.e. the atlas spkg, generally on OS X (!), doing no more and no less than creating links in $SAGE_LOCAL/lib/  the same as exist in /usr/lib/, at least on OS X 10.4 Intel. More precisely, three links pointing to the "framework" blas library:
libatlas.dylib > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib libblas.dylib > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib libcblas.dylib > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
and one more link for the "framework" lapack library (all link targets being absolute, not relative):
liblapack.dylib > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
A quick check shows that at least on OS X Intel, the absolute path to these framework libraries is the same for OS X 10.4, 10.5, 10.6, and 10.7 (I can't check for OS X 10.8), and even on OS X 10.7.3, there still is only one version "A", which is the "Current" version of that framework.
This change, for all OS X variants, would be a bit intrusive. But to me, it seems to bring the OS X world a bit closer to the situation on the other OSes. I offer to test a respectively updated atlas spkg on the OS X systems/versions I have access to. (In the "patches" subdir, one also might wish to delete the "edit" duplicates of two files, those with a tilde at the end of their file name.)
Thoughts?
comment:206 Changed 10 years ago by
I can't pretend to understand exactly what all the linking is doing here  it seems very much a black box. But those two absolute paths certainly exist on my box, and seem like a good alternative to trying to get ATLAS to build from scratch on OS X for now. I will naturally also volunteer to test on anything I have access to.
comment:207 in reply to: ↑ 199 Changed 10 years ago by
Replying to vbraun:
Replying to dimpase:
as far as CVXOPT is concerned, it does use MacOSX veclib
Are you sure? I think OSX 10.4 is rather different from modern OSX accelerate. Post the output of
otool L
on OSX 10.4 PPC or it didn't happen ;)
On 10.5 PPC it is veclib all right...
$ otool L lapack.so lapack.so: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib (compatibility version 1.0.0, current version 218.0.0)
comment:208 Changed 10 years ago by
So you mean that after
if conf['Darwin?'] \ and not os.environ.has_key('SAGE_ATLAS_ARCH'): print 'Skipping build of ATLAS on intel OS X' sys.exit(0)
in the spkginstall (well, before the exit) we should add the linking described comment:205? That would seem easy enough, though I don't know what the syntax would be (not just ln
, I assume).
comment:209 Changed 10 years ago by
 Description modified (diff)
 Status changed from needs_work to needs_review
I don't think we should be symlinking system libraries into local/lib if we can avoid it. Really cvxopt is broken, it should be linking against the accelerate blas but doesn't. In particular, we should correctly set BLAS_LIB_DIR
in cvxopt on Darwin. The update spkg fixes this. I've also changed the atlas spkg back to not build by default on Darwin. Please test the combination of both spkgs on your OSX machines.
comment:210 Changed 10 years ago by
With Sage 5.4.beta1:
applying trac_10508_root_repo.patch patching file spkg/install Hunk #2 succeeded at 363 with fuzz 1 (offset 47 lines). patching file spkg/standard/deps Hunk #2 succeeded at 60 with fuzz 1 (offset 1 lines). Hunk #4 FAILED at 525 1 out of 4 hunks FAILED  saving rejects to file spkg/standard/deps.rej patch failed, unable to continue (try v)
This is because of
# Lapack depends on SAGE_ROOT_REPO because it *executes* Fortran code at # build time. Therefore, it needs an uptodate version of sageenv # which adds $SAGE_LOCAL/lib64 to the LD_LIBRARY_PATH.
which if I recall correctly is from #13395, so this would need to be updated. For now it won't affect me building from source, so I'll just do this by hand, but I don't know the right solution to combining those two things.
comment:211 Changed 10 years ago by
 Reviewers changed from Benjamin Jones to Benjamin Jones, KarlDieter Crisman, Dmitrii Pasechnik, Georg Weber, François Bissey, John Palmieri
 Status changed from needs_review to needs_work
Here's one more issue  I have a feeling this isn't OS X specific ;)
File "/Users/.../sage5.4.beta1/devel/sagemain/sage/misc/package.py", line 119: sage: install_package() Expected: ['atlas...', 'blas...', ...] Got: ['atlas3.10.0', 'boehm_gc7.2.alpha6.p2', 'boostcropped1.34.1', 'bzip21.0.6', 'cddlib094f.p11', 'cephes2.8', 'cliquer1.2.p11', <snip>
This was a change in #11021, apparently introduced in beta0. This was on 10.7; the build will not finish for quite a while on 10.4.
Interestingly, I didn't need to apply the doctest patch, so I guess that is only in certain hardwarespecific circumstances.
comment:212 Changed 10 years ago by
And just to prove something must have happened, old versus new:
$ otool L lapack.so lapack.so: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0) /Users/.../sage5.4.beta0/local/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /Users/.../sage5.4.beta0/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
$ otool L lapack.so lapack.so: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0) /Users/.../sage5.4.beta1/local/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /Users/.../sage5.4.beta1/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
comment:213 Changed 10 years ago by
 Description modified (diff)
 Status changed from needs_work to needs_review
comment:214 Changed 10 years ago by
Edited dumb question. Here is what remains.
Is it ok that there is basically an spkg in an spkg? We just got rid of this in the R/RPy situation, but I assume this is somehow different. Somehow.
comment:215 Changed 10 years ago by
The new atlas needs the lapack tarball to build. The only alternative would be to have a separate lapack spkg that saves a tarball of its sources somewhere ;)
comment:216 followups: ↓ 217 ↓ 226 Changed 10 years ago by
it does build OK on MacOSX 10.5 PPC (namely, a G4 processor).
I'll report the result of testlong when it's done.
comment:217 in reply to: ↑ 216 Changed 10 years ago by
it does build OK on MacOSX 10.5 PPC (namely, a G4 processor).
Same on my 10.4 PPC G4 machine.
I'll report the result of testlong when it's done.
It's not done, but the failures all seem to be of the following sort  not finding lblas
:
sage t force_lib "devel/sage/sage/misc/preparser.py" ********************************************************************** File "/Users/student/Desktop/sage5.4.beta1/devel/sage/sage/misc/preparser.py", line 1526: sage: z=0; sage.misc.preparser.load(t,globals()) Expected: Compiling ....pyx... hi 0 Got: Compiling /Users/student/.sage//temp/Dasher_03.local/6088//tmp_2.pyx... Error compiling cython file: Error compiling /Users/student/.sage//temp/Dasher_03.local/6088//tmp_2.pyx: running build running build_ext building '_Users_student__sage_temp_Dasher_03_local_6088_tmp_2_pyx_0' extension creating build creating build/temp.macosx10.4ppc2.7 gcc fnostrictaliasing fwrapv DNDEBUG g fwrapv O3 Wall Wstrictprototypes I/Users/student/Desktop/sage5.4.beta1/local/include/csage/ I/Users/student/Desktop/sage5.4.beta1/local/include/ I/Users/student/Desktop/sage5.4.beta1/local/include/python2.7/ I/Users/student/Desktop/sage5.4.beta1/local/lib/python2.7/sitepackages/numpy/core/include I/Users/student/Desktop/sage5.4.beta1/devel/sage/sage/ext/ I/Users/student/Desktop/sage5.4.beta1/devel/sage/ I/Users/student/Desktop/sage5.4.beta1/devel/sage/sage/gsl/ I/Users/student/.sage//temp/Dasher_03.local/6088 I/Users/student/Desktop/sage5.4.beta1/local/include/python2.7 c _Users_student__sage_temp_Dasher_03_local_6088_tmp_2_pyx_0.c o build/temp.macosx10.4ppc2.7/_Users_student__sage_temp_Dasher_03_local_6088_tmp_2_pyx_0.o w O2 creating build/lib.macosx10.4ppc2.7 gcc bundle undefined dynamic_lookup L/Users/student/Desktop/sage5.4.beta1/local/lib build/temp.macosx10.4ppc2.7/_Users_student__sage_temp_Dasher_03_local_6088_tmp_2_pyx_0.o L/Users/student/Desktop/sage5.4.beta1/local//lib/ lmpfr lgmp lgmpxx lstdc++ lpari lm ljc lgsl lgslcblas lblas lntl lcsage o build/lib.macosx10.4ppc2.7/_Users_student__sage_temp_Dasher_03_local_6088_tmp_2_pyx_0.so L/Users/student/Desktop/sage5.4.beta1/local//lib <BLANKLINE> /usr/bin/ld: can't locate file for: lblas collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 <BLANKLINE>
comment:218 Changed 10 years ago by
Can you try to make a symlink
cd $SAGE_LOCAL/lib ln s /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib .
and run the doctests again?
comment:219 Changed 10 years ago by
I'm pretty sure all the nontimeouts are related to this.
sage t force_lib "devel/sage/sage/misc/cachefunc.pyx" sage t force_lib "devel/sage/sage/misc/cython.py" sage t force_lib "devel/sage/sage/misc/lazy_attribute.py" sage t force_lib "devel/sage/sage/misc/package.py" sage t force_lib "devel/sage/sage/misc/preparser.py" sage t force_lib "devel/sage/sage/misc/sagedoc.py" sage t force_lib "devel/sage/sage/misc/sageinspect.py" sage t force_lib "devel/sage/sage/misc/superseded.py" sage t force_lib "devel/sage/sage/parallel/decorate.py" sage t force_lib "devel/sage/sage/plot/contour_plot.py" # Time out sage t force_lib "devel/sage/sage/plot/graphics.py" # Time out sage t force_lib "devel/sage/sage/plot/plot.py" # Time out sage t force_lib "devel/sage/sage/rings/number_field/number_field_element.pyx" # Time out sage t force_lib "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py" # Time out sage t force_lib "devel/sage/sage/schemes/elliptic_curves/heegner.py" # Time out sage t force_lib "devel/sage/sage/structure/element.pyx" sage t force_lib "devel/sage/sage/structure/misc.pyx"
I'll try the symlink now.
comment:220 Changed 10 years ago by
This seems to work fine. I think that if just putting this link in the top for only PPC machines (or even only 10.4 PPC machines if Dima's tests turn out fine) would be fine. Or even some of the other links e.g. to lapack, if appropriate.
I also feel your frustration with not having an easy machine to test with. I would really like to make this one available, but the way I understand it that's not an option  at least, I tried the ssh method above and it didn't seem to work properly.
comment:221 Changed 10 years ago by
I've updated the spkg to symlink the veclib blas and lapack to $SAGE_LOCAL/lib/
on OSX PPC. This should finally work now. Please test and review!
KarlDieter, you went beyond your duty to debug this. But every platform dies eventually, you just have to notice the signs. E.g. when it starts getting more difficult than finding a SPARC box ;)
comment:222 Changed 10 years ago by
Haha! Anyway, I'll still try it out.
By the way, I presume the cvxopt changes might not be necessary (at least not the Acceleraterelated one) now, but that it also wouldn't hurt to keep them in for all Macs?
comment:223 Changed 10 years ago by
I ran also into the problem of comment 211, but I see that one is already cared for.
The latest "pyx_preparse()" problem might not be entirely due to what is done about "BLAS configuration/setup", and how it is done in .../sage/misc/cython.py (see especially lines 6467 in conjunction with lines 7879 and line 265 in that file), but certainly creates pretty exactly the kind of problem observed in comment 216, and healed by the symlink in comment 218. (It's quite a miracle to me, how that could have ever worked before under OS X 10.4 PPC  which I know it did!)
Which leaves us with either adjusting every occurence of BLAS configuration/setup (sage/module_list.py lines 2244, sage/misc/cython.py lines as above, cvxopt and possibly yet another spkg or two, ...) for the "OS X 10.4 PPC case" (we already *do* search for "/usr/lib/libclas.{so, dylib}" in those places, and use that one if one can be found there, just extend the search to "/System/Library/Frameworks/Accelerate?.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib" in case the former search failed), or else try the symlink approach. Or some "hybrid" approach, symlinking only on OS X 10.4 PPC.
@Volker:
In comment 209 you wrote:
I don't think we should be symlinking system libraries into local/lib if we can avoid it.
So if you think that creating symlinks to "outsideofsage" libraries in $SAGE_ROOT/local/lib/ (and possibly to header files like "cblas.h" and "clapack.h" in $SAGE_ROOT/local/include/, too) should be avoided, could you please give some insights about the reasoning behind?
P.S.:
I can't find the following note about trying to actually *build and use* ATLAS on OS X in the comments so far, so here it is: If we want to be able to do so one day, at least the numpy build system needs to be patched (somewhere in src/numpy/distutils/system_info.py, classes "lapack_opt_info" and "blas_opt_info"), since there the usage of the Accelerate framework on OS X is hardcoded  which seems to be problematic, if other parts of Sage do not use the same underlying LAPACK and BLAS libraries. Essentially, one should be able to "just" reuse patches from the respective Gentoo ebuilds, it has the air of a "reine Fleissarbeit" (dict.leo.org: "a diligent but routine piece of work"). Of course, any OS X 10.4 PPC specific bits and pieces would then have to "behave well", too ... (the "symlinking approach" would probably make that part rather straightforward).
P.P.S.:
Now that quite a few people are involved, wouldn't it make sense to try to clean up that current BLAS configuration/setup code parts a bit? At least between module_list.py, cython.py and the cvxopt spkg install, more or less the same functionality is tripled. Possibly by moving all this to setting (or taking over from the parent environment) "SAGE_BLAS_LIB", "SAGE_CBLAS_LIB", "SAGE_ATLAS_LIB" or the like environment variables, ensuring these are sanely set at both the start of a Sage build (prereq spkg?!), as well as in the Sage environment at runtime (sageshell?!), and then in "module_list.py", "misc/cython.py", cvxopt spkg install, ... simply referring to/using/relying on these env vars ... just letting the thoughts flow, sorry :)
P.P.P.S.:
Unfortunately, it took me so long to write this, that it this message already mostly outdated (by comments 221, 222).
comment:224 Changed 10 years ago by
While ugly, its not really a problem if some parts of the Sage install link to alternative blas implementations. Though for now I think we'll just do the symlink workaround for OSX PPC.
I'm totally against new environment variables. The proper solution IMHO is a blasconfig
script that can spit out the required options. For example, blasconfig cflags f77blas
would give you the f77 compiler flags. Then we can step by step replace all hardcoded blas guesses by blasconfig
calls. But this is stuff for a future ticket ;)
comment:225 followup: ↓ 227 Changed 10 years ago by
I'm getting a really weird build error I didn't get before on 5.4.beta1 with this stuff in it. This is on OS X 10.7.
Traceback (most recent call last): File "setup.py", line 199, in <module> check_for_dependencies() File "/Users/.../sage5.4.beta1atlas/spkg/build/ipython0.10.2.$ check_for_pexpect() File "/Users/.../sage5.4.beta1atlas/spkg/build/ipython0.10.2.$ print_status("pexpect", pexpect.__version__) AttributeError: 'module' object has no attribute '__version__' Error building IPython. real 0m0.298s user 0m0.194s sys 0m0.056s ************************************************************************ Error installing package ipython0.10.2.p1 ************************************************************************
Granted, I was using six threads, but it is repeatable. I'm going to try this again, and I really can't understand it. I haven't seen anyone give this kind of report. I also get
**************************************************** nothing changed pulling from /Users/.../sage5.4.beta1atlas/spkg/build/extcode5.4.beta1 searching for changes abort: repository is unrelated abort: merging with a working directory ancestor has no effect nothing changed 0 files updated, 0 files merged, 0 files removed, 0 files unresolved ./spkginstall: line 33: /Users/.../sage5.4.beta1atlas/data/extcode/.hg/hgrc: No such file or directory real 0m0.464s user 0m0.344s sys 0m0.108s ************************************************************************ Error installing package extcode5.4.beta1 ************************************************************************
I don't see how this could be related, but wanted to report it.
comment:226 in reply to: ↑ 216 Changed 10 years ago by
Replying to dimpase:
it does build OK on MacOSX 10.5 PPC (namely, a G4 processor).
I'll report the result of testlong when it's done.
all tests pass, no problem, without any workarounds needed for 10.4. Thus 10.5 behaves quite well.
comment:227 in reply to: ↑ 225 ; followup: ↓ 228 Changed 10 years ago by
I don't see how this could be related, but wanted to report it.
It must have been some kind of weird race condition  I did another build from scratch on 5.4.beta1 on 10.7 with these changes and only had the expected misc/package.py error taken care of by the attached patch. Sorry for the noise, and I'm certainly not going to try to track down the race condition.
Anyway, things are looking good!
comment:228 in reply to: ↑ 227 ; followup: ↓ 229 Changed 10 years ago by
Replying to kcrisman:
Anyway, things are looking good!
You are supposed to set the ticket to positive review in that case.
comment:229 in reply to: ↑ 228 ; followup: ↓ 230 Changed 10 years ago by
Anyway, things are looking good!
You are supposed to set the ticket to positive review in that case.
Am I now? There are tons of things on this ticket I know absolutely nothing about. Was this the last outstanding issue, according to the other reviewers? Will this last change cause trouble on computers other than the ones I tested it on? (I'm taking it from Georg's word that that is indeed the relevant path for those libraries on all Macs, possibly not including Mountain Lion.)
comment:230 in reply to: ↑ 229 ; followup: ↓ 231 Changed 10 years ago by
Replying to kcrisman:
Will this last change cause trouble on computers other than the ones I tested it on?
Well we either wait until this ticket is obsoleted by the next ATLAS version, test it manually on each computer on skynet, or we let the buildbot do it.
comment:231 in reply to: ↑ 230 Changed 10 years ago by
Will this last change cause trouble on computers other than the ones I tested it on?
Well we either wait until this ticket is obsoleted by the next ATLAS version, test it manually on each computer on skynet, or we let the buildbot do it.
Fair enough. I was mainly worried about Dima's computer, actually. So you're saying the rest of the ticket has already been positively reviewed? For instance, in comment:162, John says "On mark (Solaris), I see a problem building scipy." and I don't see anything resolving that (in fact, he edits it to indicate ATLAS is the problem). I am comfortable with positive review from my p.o.v., but I won't incur the wrath of Solaris fans by overriding that.
comment:232 Changed 10 years ago by
Sparc solaris isn't firsttier platform so we can always clean that up later. There is already way too much on this ticket to even pick out the comments that relate to SPARC only. And dima just reported that it worked fine for him.
comment:233 Changed 10 years ago by
 Status changed from needs_review to positive_review
Be it on your head, then! Jeroen, send all buildbot log failures to Volker directly ;)
Also, Dima reported it worked fine before the change to linking the system library directly in, though presumably if my computers on either end worked, his should.
comment:234 Changed 10 years ago by
 Status changed from positive_review to needs_work
Hah! I should have known... The symlink by hand worked, but
Skipping build of ATLAS on intel OS X Traceback (most recent call last): File "./spkginstall", line 106, in <module> ln(os.path.join(veclib_dir, lib), NameError: name 'ln' is not defined real 0m1.290s user 0m0.334s sys 0m0.501s ************************************************************************ Error installing package atlas3.10.0 ************************************************************************
That's probably because this is #!/usr/bin/env python
. I think what we need is Python's os.symlink
. I can't explain why this doesn't raise a problem on 10.7, but apparently on 10.4 it does.
comment:235 Changed 10 years ago by
I've uploaded a package at http://sage.math.washington.edu/home/kcrisman/atlas3.10.0.spkg for Volker to look at. Hopefully this will solve this last minor problem. Then he can either put this change in his or link to this one if he feels it's now positive review.
It didn't cause trouble on my other machine because it is Intel, which doesn't use this branch of the code! But it would have broken Dima's 10.5 PPC machine.
comment:236 followup: ↓ 237 Changed 10 years ago by
I thought you had tried the spkg on your machine ;)
I fixed the ln (which is actually a python function that I forgot to import). The replaced spkg should work now. And the ln is only used on OSX PPC, which is also why I can't test it myself.
comment:237 in reply to: ↑ 236 ; followup: ↓ 240 Changed 10 years ago by
 Status changed from needs_work to needs_review
I thought you had tried the spkg on your machine ;)
Nope, just the solution, which I thought you'd properly written ;)
I fixed the ln (which is actually a python function that I forgot to import). The replaced spkg should work now. And the ln is only used on OSX PPC, which is also why I can't test it myself.
Ok. I might be able to try this with my home box in a bit, otherwise it'll have to wait for the last test. But that ln
looks like a good one too.
comment:238 Changed 10 years ago by
 Description modified (diff)
Is the ATLAS spkg mentioned in the description still the correct link?
comment:239 Changed 10 years ago by
Jeroen: Yes, that is the correct link.
comment:240 in reply to: ↑ 237 Changed 10 years ago by
 Status changed from needs_review to positive_review
I fixed the ln (which is actually a python function that I forgot to import). The replaced spkg should work now. And the ln is only used on OSX PPC, which is also why I can't test it myself.
Ok. I might be able to try this with my home box in a bit, otherwise it'll have to wait for the last test. But that
ln
looks like a good one too.
It built fine.
comment:241 Changed 10 years ago by
 Dependencies changed from #13160 to #13160, #13395, #13392, #13416, #12994, #9906, #12883, #13123, #13415
 Description modified (diff)
Note that you cannot just use
sage f atlas3.9.32.spkg
to update atlas only. Many other spkgs use blas/lapack and must be rebuilt. The easiest way is to do a separate Sage installation...The cvxopt spkg needs to be updated to link correctly with this atlas release, see #10509.