Failed to build Atlas in Sage 4.5.2 on Xenon processor.
Jonathan Hanke
I'm trying to build sage 4.5.2 on a Sun Fire X4450 server (Intel Xenon processors) running Redhat linux (Enterprise edition), and get an error when building Atlas in the make script. Any comments are appreciated. Thanks,
-Jon
=)
------------------------------------------------------------------------------------------------------------------------------
ATLAS install complete. Examine
ATLAS/bin/<arch>/INSTALL_LOG/SUMMARY.LOG for details.
make[3]: Leaving directory `/home/jonhanke/sage-4.5.2/spkg/build/atlas-3.8.3.p12/ATLAS-build'
make clean
make[3]: Entering directory `/home/jonhanke/sage-4.5.2/spkg/build/atlas-3.8.3.p12/ATLAS-build'
rm -f *.o x* config?.out *core*
make[3]: Leaving directory `/home/jonhanke/sage-4.5.2/spkg/build/atlas-3.8.3.p12/ATLAS-build'
make[2]: Leaving directory `/home/jonhanke/sage-4.5.2/spkg/build/atlas-3.8.3.p12/ATLAS-build'
Finished building ATLAS core
make[2]: Entering directory `/home/jonhanke/sage-4.5.2/spkg/build/atlas-3.8.3.p12/ATLAS-build/lib'
rm -f libatlas.so liblapack.so
make libatlas.so liblapack.so libf77blas.so libcblas.so liblapack.so
make[3]: Entering directory `/home/jonhanke/sage-4.5.2/spkg/build/atlas-3.8.3.p12/ATLAS-build/lib'
ld -melf_x86_64 -shared -soname libatlas.so -o libatlas.so \
--whole-archive libatlas.a --no-whole-archive -lc -lm
ld -melf_x86_64 -shared -soname liblapack.so -o liblapack.so --whole-archive \
liblapack.a --no-whole-archive
make[3]: *** No rule to make target `libf77blas.a', needed by `libf77blas.so'. Stop.
make[3]: Leaving directory `/home/jonhanke/sage-4.5.2/spkg/build/atlas-3.8.3.p12/ATLAS-build/lib'
make[2]: *** [shared] Error 2
make[2]: Leaving directory `/home/jonhanke/sage-4.5.2/spkg/build/atlas-3.8.3.p12/ATLAS-build/lib'
Building shared ATLAS libraries failed
Failed to build ATLAS.
real 10m24.087s
user 8m38.823s
sys 1m42.460s
sage: An error occurred while installing atlas-3.8.3.p12
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /home/jonhanke/sage-4.5.2/install.log. Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/home/jonhanke/sage-4.5.2/spkg/build/atlas-3.8.3.p12 and type 'make check' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd '/home/jonhanke/sage-4.5.2/spkg/build/atlas-3.8.3.p12' && '/home/jonhanke/sage-4.5.2/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/atlas-3.8.3.p12] Error 1
make[1]: Leaving directory `/home/jonhanke/sage-4.5.2/spkg'
real 17m58.899s
user 13m25.004s
sys 4m22.452s
Error building Sage.
./sage -docbuild all html 2>&1 | tee -a dochtml.log
python: can't open file '/home/jonhanke/sage-4.5.2/devel/sage/doc/common/builder.py': [Errno 2] No such file or directory
William Stein
> Hi,
>
> I'm trying to build sage 4.5.2 on a Sun Fire X4450 server (Intel Xenon
> processors) running Redhat linux (Enterprise edition), and get an error when
> building Atlas in the make script. Any comments are appreciated. Thanks,
I just tried building 4.5.3.alpha2 on *your* computer (rosemary) in
/home/wstein/build/sage-4.5.3.alpha2 and it worked fine. Note that I
set this environment variable:
export SAGE_FAT_BINARY=yes
This changes how ATLAS is built to use a sort of "lowest common
denominator" configuration.
You might try that. It can potentially make numerical linear algebra
slower for you, but I doubt
you do a lot of that.
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Dr. David Kirkby
> On Mon, Aug 23, 2010 at 8:25 PM, Jonathan Hanke<jonh...@gmail.com> wrote:
>> Hi,
>>
>> I'm trying to build sage 4.5.2 on a Sun Fire X4450 server (Intel Xenon
>> processors) running Redhat linux (Enterprise edition), and get an error when
>> building Atlas in the make script. Any comments are appreciated. Thanks,
>
> I just tried building 4.5.3.alpha2 on *your* computer (rosemary) in
> /home/wstein/build/sage-4.5.3.alpha2 and it worked fine. Note that I
> set this environment variable:
>
> export SAGE_FAT_BINARY=yes
>
> This changes how ATLAS is built to use a sort of "lowest common
> denominator" configuration.
> You might try that. It can potentially make numerical linear algebra
> slower for you, but I doubt
> you do a lot of that.
It would be good if we knew the conditions on which this fails, so it could be
set automatically.
Have you any idea what the problem is on some machines?
I recently installed Debian - both 32-bit and 64-bit on VirtualBox virtual
machines. ATLAS would not build on either of them. It goes around the loop 5
times, trying to get consistent timing, then gives up.
Since I knew Minh had built on Debian many times on GCC build farm, I rather put
it down to something wrong with my Virtual machine setup.
Dave
William Stein
> On Mon, Aug 23, 2010 at 8:25 PM, Jonathan Hanke <jonh...@gmail.com> wrote:
>> Hi,
>>
>> I'm trying to build sage 4.5.2 on a Sun Fire X4450 server (Intel Xenon
>> processors) running Redhat linux (Enterprise edition), and get an error when
>> building Atlas in the make script. Any comments are appreciated. Thanks,
>
> I just tried building 4.5.3.alpha2 on *your* computer (rosemary) in
> /home/wstein/build/sage-4.5.3.alpha2 and it worked fine. Note that I
> set this environment variable:
>
> export SAGE_FAT_BINARY=yes
>
> This changes how ATLAS is built to use a sort of "lowest common
> denominator" configuration.
> You might try that. It can potentially make numerical linear algebra
> slower for you, but I doubt
> you do a lot of that.
Hi,
I waited for the Sage testsuite to run on rosemary (with
sage-4.5.3.alpha2), and interestingly
there are a huge number of failures, despite the building completing
fine. It looks like
every failure is "ImportError: No module named scipy". This suggests
that despite the build
of Sage exiting with an error, for some reason the exit code was still
zero, so the testsuite got run.
Checking further I see that PIL failed to build:
/usr/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg
/usr/bin/ld: /usr/local/lib/libpython2.6.a(abstract.o): relocation R_X86_64_32 a
gainst `a local symbol' can not be used when making a shared object; recompile w
ith -fPIC
/usr/local/lib/libpython2.6.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
Error building PIL: 'Error installing PIL'
real 0m10.521s
user 0m8.155s
sys 0m2.290s
sage: An error occurred while installing pil-1.1.6.p2
--
This means that building Sage-4.5.3 at least is totally broken on
rosemary.math.uga.edu. This could be the result of you installing a
new systemwide package, or something else (I don't know). Everything
below may be of interest to Sage developers, but probably not to you
-- it's not specific to your problem.
---
OK, trying again by hand we have in SAGE_ROOT on rosemary.math
building sage-4.5.3.alpha2:
$ make
...
gcc -pthread -shared build/temp.linux-x86_64-2.6/_imaging.o build/temp.linux-x8o
/usr/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg
/usr/bin/ld: /usr/local/lib/libpython2.6.a(abstract.o): relocation R_X86_64_32 C
/usr/local/lib/libpython2.6.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
Error building PIL: 'Error installing PIL'
real 0m10.397s
user 0m8.101s
sys 0m2.253s
sage: An error occurred while installing pil-1.1.6.p2
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /home/wstein/build/sage-4.5.3.alpha2/install.log. Describe your computer, o.
If you want to try to fix the problem yourself, *don't* just cd to
...
Error building Sage.
./sage -docbuild all html 2>&1 | tee -a dochtml.log
sphinx-build -b html -d /home/wstein/build/sage-4.5.3.alpha2/devel/sage/doc/outs
Running Sphinx v0.6.3
loading pickled environment... done
building [html]: targets for 0 source files that are out of date
$ echo $?
0
The seriously confusing to me issue is that make ignores that a component fails
to build, then builds the documentation. This then succeeds, which
results in a 0 exit code.
This is somehow the result of the following makefile:
#######################################
all: build doc
build:
cd spkg && ./install all 2>&1 | tee -a ../install.log
doc: doc-html
doc-html: build
./sage -docbuild all html $(SAGE_DOCBUILD_OPTS) 2>&1 | tee -a dochtml.lo
#######################################
Maybe ./install is doing the wrong thing? So I just try explicitly doing:
./sage -sh
cd spkg
./install all
echo $?
and I get 1 as output, as expected. Next I try:
$ cd spkg && ./install all 2>&1 | tee -a ../install.log
$ echo $?
0
Dang! So maybe there is something foo-bared about how we are using tee?
Yes, definitely, since:
$ cd spkg && ./install all 2>&1
$ echo $?
1
There is a page about how to deal with this subtle problem here:
I think this will be painful to fix.
This is now trac 9799: http://trac.sagemath.org/sage_trac/ticket/9799
Dr. David Kirkby
> On Tue, Aug 24, 2010 at 1:38 PM, William Stein<wst...@gmail.com> wrote:
>> On Mon, Aug 23, 2010 at 8:25 PM, Jonathan Hanke<jonh...@gmail.com> wrote:
>>> Hi,
>>>
>>> I'm trying to build sage 4.5.2 on a Sun Fire X4450 server (Intel Xenon
>>> processors) running Redhat linux (Enterprise edition), and get an error when
>>> building Atlas in the make script. Any comments are appreciated. Thanks,
>>
>> I just tried building 4.5.3.alpha2 on *your* computer (rosemary) in
>> /home/wstein/build/sage-4.5.3.alpha2 and it worked fine. Note that I
>> set this environment variable:
>>
>> export SAGE_FAT_BINARY=yes
>>
>> This changes how ATLAS is built to use a sort of "lowest common
>> denominator" configuration.
>> You might try that. It can potentially make numerical linear algebra
>> slower for you, but I doubt
>> you do a lot of that.
>
> Hi,
>
> I waited for the Sage testsuite to run on rosemary (with
> sage-4.5.3.alpha2), and interestingly
What is rosemary.math? Does it happen to have an Opteron processor?
> there are a huge number of failures, despite the building completing
> fine. It looks like
> every failure is "ImportError: No module named scipy". This suggests
> that despite the build
> of Sage exiting with an error, for some reason the exit code was still
> zero, so the testsuite got run.
> Checking further I see that PIL failed to build:
>
> /usr/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg
> /usr/bin/ld: /usr/local/lib/libpython2.6.a(abstract.o): relocation R_X86_64_32 a
> gainst `a local symbol' can not be used when making a shared object; recompile w
> ith -fPIC
I've not looked at the code, but it is *often* possible to get away without
compiling libraries with position independent code. But this is not reliable.
Until recently, Singular compiled without PIC code on 32-bit build builds,
except on I think Opteron processors. The developers belived this was only
necessary on 64-bit and IIRC on Opteron processors.
After a lot of discussion, I finally managed to convince the Singular developers
that building without PIC code is unreliable. This is very clearly documented in
the Sun linker manual, and a bit less so in the GCC manual. So now Singular
builds PIC on every platform all the time.
There's a small performance disadvantage with this, which the Singular
developers measured at around 5%.
So *IF* that library is not being built PIC, then I am not surprised it fails on
some systems at some times.
Dave
Mitesh Patel
> On Tue, Aug 24, 2010 at 1:38 PM, William Stein <wst...@gmail.com> wrote:
>> On Mon, Aug 23, 2010 at 8:25 PM, Jonathan Hanke <jonh...@gmail.com> wrote:
>>> Hi,
>>>
>>> I'm trying to build sage 4.5.2 on a Sun Fire X4450 server (Intel Xenon
>>> processors) running Redhat linux (Enterprise edition), and get an error when
>>> building Atlas in the make script. Any comments are appreciated. Thanks,
>>
>> I just tried building 4.5.3.alpha2 on *your* computer (rosemary) in
>> /home/wstein/build/sage-4.5.3.alpha2 and it worked fine. Note that I
>> set this environment variable:
>>
>> export SAGE_FAT_BINARY=yes
>>
>> This changes how ATLAS is built to use a sort of "lowest common
>> denominator" configuration.
>> You might try that. It can potentially make numerical linear algebra
>> slower for you, but I doubt
>> you do a lot of that.
>
The PIL error is
Dr. David Kirkby
See
http://groups.google.com/group/sage-devel/msg/fbd62a23fe1dcffa?hl=en-GB&
This boils down to the fact the wrong Python libraries are used - see #9209.
This has bugged me on some Solaris systems, and seems to be an issue on Red Hat
Linux too.
Dave
jonh...@gmail.com
I just built sage-4.6 on this machine (Sun Fire X4450 -- with Xenon
processors), and it passes all doctests except for one (see below),
even though the trac ticket
http://trac.sagemath.org/sage_trac/ticket/9864
was postponed to be fixed in 4.6.1. Thanks to whomever mostly fixed
this!
-Jon
=)
jonhanke@[~/my_sage_dir/SAGE_parsley_Build_Testing/sage-4.6]: sage -t
"devel/sage/sage/interfaces/qepcad.py"
sage -t "devel/sage/sage/interfaces/qepcad.py"
Non-default server settings detected:
Incoming Server = http://hg.sagemath.org (default)
Outgoing Server = ssh://jonh...@sage.math.washington.edu/sage-4.1.1/devel
Traceback (most recent call last):
File "/home/jonhanke/.sage//tmp/qepcad.py", line 18, in <module>
from qepcad import *
File "/home/jonhanke/.sage/tmp/qepcad.py", line 543, in <module>
from expect import Expect, ExpectFunction, AsciiArtString
ImportError: No module named expect
[1.6 s]
----------------------------------------------------------------------
The following tests failed:
sage -t "devel/sage/sage/interfaces/qepcad.py"
Total time for all tests: 1.6 seconds
Jan Groenewald
On Thu, Nov 04, 2010 at 12:34:50AM -0700, jonh...@gmail.com wrote:
> jonhanke@[~/my_sage_dir/SAGE_parsley_Build_Testing/sage-4.6]: sage -t
> "devel/sage/sage/interfaces/qepcad.py"
> from expect import Expect, ExpectFunction, AsciiArtString
> ImportError: No module named expect
I'm not sure this is related.
We had students install
/scratchspace/sage
while there is a sage in /usr/local/bin/sage
When they did make testlong, sage -t ....r.py failed with the same
expect ImportError.
It seemd to be that sage -t was calling the systemwide sage
to test the scratchspace sage, which is very odd.
Rerunning sage -t kept giving the error.
Running /scratchspace$ ./sage -t gave no error.
regards,
Jan
--
.~.
/V\ Jan Groenewald
/( )\ www.aims.ac.za
^^-^^