#7375: upgrade M4RI to newest upstream release
---------------------------+------------------------------------------------
Reporter: malb | Owner: tbd
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.3
Component: packages | Keywords: M4RI, linear algebra
Work_issues: | Author: Martin Albrecht
Reviewer: drkirkby | Merged:
---------------------------+------------------------------------------------
Changes (by drkirkby):
* cc: david.kir...@… (added)
Comment:
Hi,
I checked libm4ri-20091119.spkg on two UNIX workstations.
* Sun Blade 2000, Solaris 10 update 7, 2 x 1200 MHz UltraSPARC IV+
processors, 8 GB RAM, Sun Studio 12.1 compiler.
* HP C3600, HP-UX 11.11, 1 x 552 MHz PA-RISC processor, 8 GB RAM, gcc
4.4.0.
I hope the results of the tests are useful. Sorry if some of these existed
in your earlier spkg-install, and I forgot to mention them, but I did
admit I was under the influence of alcohol!
== General points ==
* In spkg-install, if the tests fail, there is a message generated to say
to report this upstream. It would be useful if that message could say
where to - i.e. a web site, email address etc. Things are more likely to
be reported upstream if someone can easily find where to report it to. I
actually like the idea of suggesting to report this upstream. Other
packages should follow your example.
* Since the current environment script enforces SAGE_64 to be "yes" or
"no", then I think for consistency we should do the same for "SAGE_DEBUG".
So I would change the
{{{
if [ "$SAGE_DEBUG" = "1" ];
}}}
to
{{{
if [ "x$SAGE_DEBUG" = "xyes" ];
}}}
However, there was a consensus some time back that the default should be
to build with debug information present (-g flag) and only if SAGE_DEBUG
was set to "no" should -g not be there.
However, adding your --enable-debug flag to the configure script might
have a serious impact on performance, in which case you should not enable
that by default. You can best judge how to handle that.
* One bit of code has this:
{{{
CFLAGS="$CFLAGS $INCLUDES -L$SAGE_LOCAL/lib -pedantic -g"
}}}
So -pedantic and -g are CFLAGS. This has two problems. First, -pedantic is
a GNU specific flag. Secondly, there is the issue of whether the -g flag
should be there or not. The '-g' flag does appear to be a portable flag,
so should not be a problem on any compiler I know of.
Now to the results.
== Results on HP-UX 11.11 with gcc 4.4.0 ==
M4RI configured properly, without aborting when trying to find the cache
size, as reported in #7171.
The package went on to compile ok on HP-UX, and passed all tests. That is
certainly better than many packages.
There was however a few things that perhaps can be addressed. One is HP-UX
specific, so I would not bother trying to fix that, but the other two I
believe will happen on other platforms too.
* There were repeated messages about redefining CPU_L1_CACHE and
CPU_L2_CACHE.
{{{
In file included from src/brilliantrussian.c:22:
src/misc.h:359:1: warning: "CPU_L2_CACHE" redefined
In file included from src/misc.h:33,
from src/brilliantrussian.c:22:
src/config.h:8:1: warning: this is the location of the previous definition
In file included from src/brilliantrussian.c:22:
src/misc.h:367:1: warning: "CPU_L1_CACHE" redefined
}}}
this happened on numerous files. Since the cache size will not be
determined on Solaris, I might assume the same would happen there. Is
there a way you can work around that, so the warning is not generated? It
does not look very impressive to see warnings, but your package is still a
'''lot''' better than many others in this respect.
* libtool gave a warning, which is probably specific to HP-UX, so I would
certainly not worry about this, but for completeness, the warning was:
{{{
./m4ri/config.h:5:1: warning: this is the location of the previous
definition
mv -f .deps/test_kernel.Tpo .deps/test_kernel.Po
/bin/sh ./libtool --tag=CC --mode=link gcc -std=gnu99
-I/home/drkirkby/sage-4.2/local/include/
-L/home/drkirkby/sage-4.2/local/lib -pedantic -g -fPIC -Wall -O2 -lm4ri
-lm -o test_kernel test_kernel.o
libtool: link: warning: this platform does not like uninstalled shared
libraries
libtool: link: warning: `test_kernel' will be relinked during installation
}}}
* I'm not sure if the following is done by libtool, or whether you have
done it, but some bits of code are compiling with gcc with the -Wall
option to show all warnings, then sends all warnings to /dev/null. It
seems a bit silly. If it in your code, I would suggest you remove it. If
it's something done by libtool, and not easily within your control, then
leave it.
So overall, on HP-UX, this is pretty good, though perhaps you can sort out
at least the first of these.
== Results on Solaris 10 update 7 (SPARC) with Sun Studio 12.1 compiler
==
Here things were not as successful as on HP-UX with gcc.
4MRI will not build with Sun Studio.
{{{
libm4ri-20091119/testcc.sh
Finished extraction
****************************************************
Host system
uname -a:
SunOS swan 5.10 Generic_139555-08 sun4u sparc SUNW,Sun-Blade-1000
****************************************************
****************************************************
CC Version
/opt/xxxsunstudio12.1/bin/cc -v
usage: cc [ options] files. Use 'cc -flags' for details
****************************************************
make: *** No rule to make target `clean'. Stop.
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... /opt/xxxsunstudio12.1/bin/cc
checking for C compiler default output file name...
configure: error: in
`/export/home/drkirkby/sage-4.2/spkg/build/libm4ri-20091119/src':
configure: error: C compiler cannot create executables
See `config.log' for more details.
Error configuring libm4ri
real 0m2.911s
user 0m0.712s
sys 0m1.285s
sage: An error occurred while installing libm4ri-20091119
}}}
Whilst the -Wall and -fPIC flags are no longer being sent to the compiler,
the -pedantic flag is getting to the compiler from spkg-install. I think
that is what is preventing the Sun compiler from building an executable.
I'm attaching another config.log generated on Solaris with the Sun
compiler. I think the reason for the failure is pretty simple to sort out.
I'm not sure if you need both -Wall and -pedantic (I don't know exactly
what they are each supposed to do), but removing the -pedantic flag near
the top of spkg-install, and adding in like this:
{{{
if [ "x$COMPILER" = "xGNU" ] ; then
CFLAGS="$CFLAGS -fPIC -Wall -pedantic"
elif [ "x$COMPILER" = "xSun_on_Solaris" ] ; then
CLFAGS="$CLFAGS -Kpic "
elif [ "x$COMPILER" = "xHP_on_HPUX" ] ; then
CFLAGS="$CFLAGS + z "
fi
}}}
will probably do the trick. Then it will only get added on GNU compilers,
so should not prevent it building on Solaris 10.
Dave
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7375#comment:10>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=.
