Closed 85eec1a4-3d04-4b4d-b711-d4db03337c41 closed 13 years ago
do you want me to test the svn version on this machine?
yes, as upstream developer I cannot help unless you report a problem with the (vanilla) upstream version.
Of course you are also free to solve the problem within Sage, but if it is not due to the Sage packaging, it would be useful to report it upstream.
Paul Zimmermann
Replying to @zimmermann6:
do you want me to test the svn version on this machine?
yes, as upstream developer I cannot help unless you report a problem with the (vanilla) upstream version.
OK, I got the svn version, cd to trunk, and am stuck:
$ autoconf
configure.in:8: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:81: error: possibly undefined macro: AM_CONDITIONAL
configure.in:155: error: possibly undefined macro: AM_PROG_AS
configure.in:156: error: possibly undefined macro: AM_PROG_CC_C_O
configure.in:185: error: possibly undefined macro: AC_OPENMP
Am I doing something wrong, or my autoconf is too old?
Dima
Of course you are also free to solve the problem within Sage, but if it is not due to the Sage packaging, it would be useful to report it upstream.
Paul Zimmermann
Replying to @dimpase:
$ autoconf configure.in:8: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:81: error: possibly undefined macro: AM_CONDITIONAL configure.in:155: error: possibly undefined macro: AM_PROG_AS configure.in:156: error: possibly undefined macro: AM_PROG_CC_C_O configure.in:185: error: possibly undefined macro: AC_OPENMP
Try the following instead:
$ autoreconf -i
If this doesn't work, please post the output of
$ autoconf --version
$ automake --version
you can also try the snapshot from http://www.loria.fr/~zimmerma/ecm-6.3.1.tar.gz (note this is NOT a release).
Paul Zimmermann
Replying to @dimpase:
Replying to @zimmermann6:
do you want me to test the svn version on this machine?
yes, as upstream developer I cannot help unless you report a problem with the (vanilla) upstream version.
OK, I got the svn version, cd to trunk, and am stuck:
oops, please ignore this; I should have read README.dev...
Dima
Replying to @zimmermann6:
you can also try the snapshot from http://www.loria.fr/~zimmerma/ecm-6.3.1.tar.gz
this one builds (with GMP provided by MPIR) and passes all tests on this computer (macosx 10.5 ppc G4), without any specific configure flags...
(note this is NOT a release).
Paul Zimmermann
Dima
Replying to @jdemeyer:
Try the following instead:
with current autotools from gnu.org:
$ autoreconf -i
configure.in:106: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:106: the top level
configure.in:111: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:111: the top level
configure.in:139: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:139: the top level
configure.in:106: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:106: the top level
configure.in:111: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:111: the top level
configure.in:139: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:139: the top level
configure.in:106: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:106: the top level
configure.in:111: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:111: the top level
configure.in:139: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:139: the top level
configure.in:106: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:106: the top level
configure.in:111: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:111: the top level
configure.in:139: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:139: the top level
configure.in:106: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:106: the top level
configure.in:111: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:111: the top level
configure.in:139: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:198: AC_LANG_CONFTEST is expanded from...
configure.in:139: the top level
configure.in:156: installing `./compile'
configure.in:10: installing `./config.guess'
configure.in:10: installing `./config.sub'
configure.in:8: installing `./install-sh'
configure.in:8: installing `./missing'
athlon/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
athlon/Makefile.am:9: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
athlon/Makefile.am:9: to `configure.in' and run `aclocal' and `autoconf' again.
athlon/Makefile.am:9: If `AC_PROG_LIBTOOL' is in `configure.in', make sure
athlon/Makefile.am:9: its definition is in aclocal's search path.
pentium4/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
pentium4/Makefile.am:9: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
pentium4/Makefile.am:9: to `configure.in' and run `aclocal' and `autoconf' again.
pentium4/Makefile.am:9: If `AC_PROG_LIBTOOL' is in `configure.in', make sure
pentium4/Makefile.am:9: its definition is in aclocal's search path.
powerpc64/Makefile.am:10: Libtool library used but `LIBTOOL' is undefined
powerpc64/Makefile.am:10: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
powerpc64/Makefile.am:10: to `configure.in' and run `aclocal' and `autoconf' again.
powerpc64/Makefile.am:10: If `AC_PROG_LIBTOOL' is in `configure.in', make sure
powerpc64/Makefile.am:10: its definition is in aclocal's search path.
x86_64/Makefile.am:12: Libtool library used but `LIBTOOL' is undefined
x86_64/Makefile.am:12: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
x86_64/Makefile.am:12: to `configure.in' and run `aclocal' and `autoconf' again.
x86_64/Makefile.am:12: If `AC_PROG_LIBTOOL' is in `configure.in', make sure
x86_64/Makefile.am:12: its definition is in aclocal's search path.
Makefile.am:8: Libtool library used but `LIBTOOL' is undefined
Makefile.am:8: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
Makefile.am:8: to `configure.in' and run `aclocal' and `autoconf' again.
Makefile.am:8: If `AC_PROG_LIBTOOL' is in `configure.in', make sure
Makefile.am:8: its definition is in aclocal's search path.
Makefile.am: installing `./depcomp'
autoreconf: automake failed with exit status: 1
$
If this doesn't work, please post the output of
$ autoconf --version
autoconf (GNU Autoconf) 2.68
[...]
Written by David J. MacKenzie and Akim Demaille.
$ automake --version
automake (GNU automake) 1.11
[...]
As well:
$ aclocal
$ automake -c -a
$ autoconf
$ ./configure
[...]
checking whether gcc and cc understand -c and -o together... yes
./configure: line 4661: syntax error near unexpected token `2.2.6'
./configure: line 4661: `LT_PREREQ(2.2.6)'
I see exactly the same error as the latter on Debian squeeze x86_64.
Replying to @dimpase:
Replying to @zimmermann6:
you can also try the snapshot from http://www.loria.fr/~zimmerma/ecm-6.3.1.tar.gz
this one builds (with GMP provided by MPIR) and passes all tests on this computer (macosx 10.5 ppc G4), without any specific configure flags...
this confirms the problem is fixed upstream, and the patch at comment 24 should be enough.
Paul
Replying to @nexttime:
Replying to @jdemeyer:
Replying to @nexttime:
Jeroen, can you try configuring with
--disable-asm-redc
?The build (outside of Sage) works.
Well, I'm a bit unsure what to do now. I can of course include the patch, but that does not what we actually want (it's just a work-around).
Well, since the patch comes from upstream and fixes the problem is all known cases, I think it makes sense to make a new ecm spkg with this patch included. Leif, what do you think (and could you make the spkg? YES/NO)
Replying to @zimmermann6:
in fact this bug is already fixed upstream (in revision 1516), see https://gforge.inria.fr/tracker/index.php?func=detail&aid=10646&group_id=135&atid=623
The patch is the following: [...]
Please can you check it works correctly with this patch?
I wish I could. The patch is against configure.in. But I cannot make autotools work on the package, neither on any local machine, nor on boxen (where autoreconf is version 2.61):
dima@boxen:/tmp/ecm-6.3.p0/src$ autoreconf -i
Remember to add `AC_PROG_LIBTOOL' to `configure.in'.
libtoolize: `config.guess' exists: use `--force' to overwrite
libtoolize: `config.sub' exists: use `--force' to overwrite
libtoolize: `ltmain.sh' exists: use `--force' to overwrite
configure.in:185: error: possibly undefined macro: AC_OPENMP
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
dima@boxen:/tmp/ecm-6.3.p0/src$
sorry...
Dima
Paul
Changed author from Mike Hansen, Leif Leonhardy to Mike Hansen, Leif Leonhardy, Jeroen Demeyer
New spkg with upstream patch from comment:24: http://sage.math.washington.edu/home/jdemeyer/spkg/ecm-6.3.p1.spkg
I still have to test it properly though.
Changed work issues from include patch for 32-bit ppc to none
Description changed:
---
+++
@@ -16,6 +16,6 @@
some assembler do not support binary constants
-New spkg: http://spkg-upload.googlecode.com/files/ecm-6.3.p0.spkg +New spkg: http://sage.math.washington.edu/home/jdemeyer/spkg/ecm-6.3.p1.spkg
Testing distribution (including #8664): http://sage.math.washington.edu/home/jdemeyer/release/sage-4.6.1.alpha0-mpir/sage-4.6.1.alpha0-mpir.tar
patch from p0 to p1, for review
Attachment: ecm-6.3.p1.patch.gz
Merged: sage-4.6.1.alpha1
Tested new spkg succesfully on the previously-failing OS X 10.4 PPC machine.
Changed reviewer from Leif Leonhardy to Leif Leonhardy, Dima Pasechnik
Replying to @jdemeyer:
Tested new spkg succesfully on the previously-failing OS X 10.4 PPC machine.
works on MacOSX 10.5 PPC. Positive review!
There is some serious trouble with this spkg: #10252
Changed merged from sage-4.6.1.alpha1 to none
Just for the record:
$ hg status
M .hgignore
M SPKG.txt
M spkg-install
A patches/configure.patch
I would still prefer to use the extended instruction set on capable PowerPCs (cf. this comment above), regardless if the operating system's ABI is 32 bit or not. (And the configure
file in patches/
is huge, as usual, though not under revision control.)
New spkg: http://spkg-upload.googlecode.com/files/ecm-6.3.p2.spkg
md5sum: 85eabecaa8974a270d5587ef8de06da1 ecm-6.3.p2.spkg
Please build, test and report!
(As you know, it still requires the new MPIR spkg from #8664. Note that I didn't have the same versions of autotools, so the patched configure
looks quite different and might give warnings, but works, at least for me.)
Description changed:
---
+++
@@ -16,6 +16,15 @@
some assembler do not support binary constants
-New spkg: http://sage.math.washington.edu/home/jdemeyer/spkg/ecm-6.3.p1.spkg +--- + +Old spkg: http://sage.math.washington.edu/home/jdemeyer/spkg/ecm-6.3.p1.spkg
Testing distribution (including #8664): http://sage.math.washington.edu/home/jdemeyer/release/sage-4.6.1.alpha0-mpir/sage-4.6.1.alpha0-mpir.tar
+
+---
+
+New spkg: http://spkg-upload.googlecode.com/files/ecm-6.3.p2.spkg
+
+md5sum: 85eabecaa8974a270d5587ef8de06da1 ecm-6.3.p2.spkg
+
FWIW, you can also test this package with the old MPIR (1.2.2), or some older GMP. Should work as well.
Ooops, I just noticed I've cleaned up a little bit too much (and did not enable building also a shared library by default).
As is, the Sage library won't build with the new package, unless you either install it with
CFLAGS
containing (also) -fPIC
, orECM_EXTRA_OPTS=--enable-shared
.(Both together also works. So yet another reason we have to pass our custom CFLAGS
.)
I'll update the spkg later, after some feedback I think.
Replying to @nexttime:
As is, the Sage library won't build with the new package, unless you either install it with
CFLAGS
containing (also)-fPIC
, or
ECM_EXTRA_OPTS=--enable-shared
.
Another option is to pass ECM_EXTRA_OPTS=--with-pic
, not sure if this works on all platforms.
Just for the record: I'll also update the MPIR spkg s.t. we can get "tuned" CFLAGS
from it (essentially some potentially better / more specific -march=...
for non-x86 systems).
The current GMP-ECM spkg uses -march=native
on x86 / x86_64 systems.
just a comment: the ticket title mentions ECM 6.3, but the changes in the description refer to changes between 6.2.1 and 6.2.2.
Paul
Leif: why not let ECM use MPIR's CFLAGS? It seems to me like you're making this package more complicated that it should be.
Sorry, but this will totally break C compilers which do not support -march=native
:
case "`uname -m`" in
i[3456]86|i86pc|x86_64|amd64)
# Only add it if CFLAGS do not already contain similar:
if ! (echo "$CFLAGS" | egrep -- '-march=|-mcpu=|-mtune=' >/dev/null);
then
CFLAGS="-march=native $CFLAGS"
fi;;
esac
On sage.math.washington.edu, I get a failure while installing the Sage library (sage-4.6.1.alpha2 + #8664 + #5847):
building 'sage.ext.interpreters.wrapper_el' extension
gcc -pthread -shared build/temp.linux-x86_64-2.6/sage/libs/libecm.o -L/mnt/usb1/scratch/jdemeyer/merger/sage-4.6.1.alpha2-mpir/local//lib
-L/scratch/jdemeyer/merger/sage-4.6.1.alpha2-mpir/local/lib -lcsage -lecm -lgmp -lstdc++ -lntl -lpython2.6 -o build/lib.linux-x86_64-2.6/sage/libs/libecm.so
/usr/bin/ld: /mnt/usb1/scratch/jdemeyer/merger/sage-4.6.1.alpha2-mpir/local//lib/libecm.a(libecm_la-factor.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/mnt/usb1/scratch/jdemeyer/merger/sage-4.6.1.alpha2-mpir/local//lib/libecm.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
Description changed:
---
+++
@@ -18,9 +18,7 @@
---
-Old spkg: [http://sage.math.washington.edu/home/jdemeyer/spkg/ecm-6.3.p1.spkg](http://sage.math.washington.edu/home/jdemeyer/spkg/ecm-6.3.p1.spkg)
-
-Testing distribution (including #8664): [http://sage.math.washington.edu/home/jdemeyer/release/sage-4.6.1.alpha0-mpir/sage-4.6.1.alpha0-mpir.tar](http://sage.math.washington.edu/home/jdemeyer/release/sage-4.6.1.alpha0-mpir/sage-4.6.1.alpha0-mpir.tar)
+Previous spkg: [http://sage.math.washington.edu/home/jdemeyer/spkg/ecm-6.3.p1.spkg](http://sage.math.washington.edu/home/jdemeyer/spkg/ecm-6.3.p1.spkg)
---
Replying to @jdemeyer:
Sorry, but this will totally break C compilers which do not support
-march=native
:
case "`uname -m`" in
i[3456]86|i86pc|x86_64|amd64)
# Only add it if CFLAGS do not already contain similar:
if ! (echo "$CFLAGS" | egrep -- '-march=|-mcpu=|-mtune=' >/dev/null);
then
CFLAGS="-march=native $CFLAGS"
fi;;
esac
Well, cite properly:
...
if [ "$SAGE_FAT_BINARY" = yes ]; then
echo "Warning: SAGE_FAT_BINARY is currently not really supported by this package."
# XXX Disable SSE2 on x86? (by passing '--enable-sse2=no' to 'configure')
# XXX Disable asm-redc? Or pass some "generic" '--host=...' to 'configure'?
else
# XXX We don't yet test if CC is really gcc here.
# gcc's "-march=native" only works on some platforms:
case "`uname -m`" in
i[3456]86|i86pc|x86_64|amd64)
# Only add it if CFLAGS do not already contain similar:
if ! (echo "$CFLAGS" | egrep -- '-march=|-mcpu=|-mtune=' >/dev/null);
then
CFLAGS="-march=native $CFLAGS"
fi;;
esac
fi
...
(There are also notes on this in both the changelog and the Special Update/Build Instructions, see above.)
What C compilers does Sage currently support (and will Sage support in the near future)?
Cf. this comment: There's very little support for other compilers in Sage, and it's easy to add a distinction when the day it gets necessary comes, though I could add it now.
Btw, if a user decides or has to set CC
for some reason (which might even be just to use a different gcc
), GMP-ECM won't use MPIR's / GMP's CFLAGS
either. And MPIR isn't omniscient...
Replying to @jdemeyer:
On sage.math.washington.edu, I get a failure while installing the Sage library (sage-4.6.1.alpha2 + #8664 + #5847):
building 'sage.ext.interpreters.wrapper_el' extension
gcc -pthread -shared build/temp.linux-x86_64-2.6/sage/libs/libecm.o -L/mnt/usb1/scratch/jdemeyer/merger/sage-4.6.1.alpha2-mpir/local//lib -L/scratch/jdemeyer/merger/sage-4.6.1.alpha2-mpir/local/lib -lcsage -lecm -lgmp -lstdc++ -lntl -lpython2.6 -o build/lib.linux-x86_64-2.6/sage/libs/libecm.so
/usr/bin/ld: /mnt/usb1/scratch/jdemeyer/merger/sage-4.6.1.alpha2-mpir/loca//lib/libecm.a(libecm_la-factor.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/mnt/usb1/scratch/jdemeyer/merger/sage-4.6.1.alpha2-mpir/local//lib/libecm.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
Do you read the comments?
P.S.: As I said, I first want to get some test results (e.g. on PowerPCs etc.) before I upload further changes.
Replying to @nexttime:
What C compilers does Sage currently support (and will Sage support in the near future)?
Okay, I was referring to older versions of gcc
which do not support -march=native
(it is a relatively new command line option, so we cannot assume that it will work).
Anyway, the proper way to do this is to actually run gcc -march=native
on some stupid .c file and check whether it compiles (there is no need to actually run the compiled program, so we can compile to /dev/null
).
Replying to @jdemeyer:
Replying to @nexttime:
What C compilers does Sage currently support (and will Sage support in the near future)?
Okay, I was referring to older versions of
gcc
which do not support-march=native
(it is a relatively new command line option, so we cannot assume that it will work).
At least since four years ago, don't know the exact version...
Anyway, the proper way to do this is to actually run
gcc -march=native
on some stupid .c file and check whether it compiles (there is no need to actually run the compiled program, so we can compile to/dev/null
).
gcc -v -march=native
should be sufficient, since the preprocessor also needs to know about it.
Replying to @nexttime:
Replying to @jdemeyer:
Replying to @nexttime:
What C compilers does Sage currently support (and will Sage support in the near future)?
Okay, I was referring to older versions of
gcc
which do not support-march=native
(it is a relatively new command line option, so we cannot assume that it will work).At least since four years ago, don't know the exact version...
GCC 4.0.1 might not support it (could you test that on an x86 machine?); GCC 4.2.1 certainly does.
Replying to @nexttime:
Replying to @nexttime:
Replying to @jdemeyer:
Replying to @nexttime:
What C compilers does Sage currently support (and will Sage support in the near future)?
Okay, I was referring to older versions of
gcc
which do not support-march=native
(it is a relatively new command line option, so we cannot assume that it will work).At least since four years ago, don't know the exact version...
GCC 4.0.1 might not support it (could you test that on an x86 machine?); GCC 4.2.1 certainly does.
... and 4.1.2 also does.
Replying to @nexttime:
gcc -v -march=native
should be sufficient, since the preprocessor also needs to know about it.
No, that's not sufficient to test it, it does not run the preprocessor.
If you want to run to preprocessor, the following works:
gcc -march=native -E -x c /dev/null -o /dev/null
Using this test, -march=native
works for me on gcc 4.2.3, NOT on gcc 4.0.3
Replying to @jdemeyer:
Replying to @nexttime:
gcc -v -march=native
should be sufficient, since the preprocessor also needs to know about it.No, that's not sufficient to test it, it does not run the preprocessor.
If you want to run to preprocessor, the following works:
gcc -march=native -E -x c /dev/null -o /dev/null
gcc -march=... -dM -E -x c /dev/null
e.g. outputs the definitions of predefined macros like __i386__
, __core2__
, __SSE2__
etc.
Using this test,
-march=native
works for me on gcc 4.2.3, NOT on gcc 4.0.3
Thanks, I use:
if touch foo.c && $CC -march=native -c foo.c &>/dev/null; then
...
fi
rm -f foo.*
Funny: GCC 4.3.3 and 4.4.3 don't build GCC 4.0.1 on Ubuntu 9.04 or 10.04... ;-)
Replying to @nexttime:
Thanks, I use:
if touch foo.c && $CC -march=native -c foo.c &>/dev/null; then ... fi rm -f foo.*
That's the best way. I would add -o /dev/null
so you don't need rm -f foo.*
but that's a minor point.
I'm still thinking that these changes should go to the mpir package and that ecm should use the default CFLAGS
provided by mpir.
Description changed:
---
+++
@@ -1,5 +1,26 @@
+Changes between ecm-6.2.3 and ecm-6.3: + New assembly code for 64-bit PowerPC (thanks to Philip McLaughlin) + Allow several processes to write to the same -save file + More routines in new P+-1 stage 2 use multi-threading in OpenMP build + Fixed incompatibility with GMP 5.0.0 + Fixed several bugs, and now check return value from malloc() calls + Fixed linking of GMP which prevented successful builds under Darwin
+Changes between ecm-6.2.2 and ecm-6.2.3: + Fixed incompatibility with GMP 4.3.0 when testing version in configure + SSE2 asm code for Visual C added in stage 2 NTT code + Small improvement to x86_64 mulredc asm code, slight speedup on Core 2 + Fixed incorrect carry propagation in subquadratic REDC code which
Changes between ecm-6.2.1 and ecm-6.2.2:
Replying to @zimmermann6:
just a comment: the ticket title mentions ECM 6.3, but the changes in the description refer to changes between 6.2.1 and 6.2.2.
That's a historical relict; I've now also added the other changes between Sage's current version and 6.3.
Changed keywords from none to MPIR elliptic curves libecm
Replying to @nexttime:
P.S.: As I said, I first want to get some test results (e.g. on PowerPCs etc.) before I upload further changes.
Although (or because) there's not much feedback yet, I've uploaded a corrected spkg (still p2) with also some other changes. This obsoletes setting ECM_EXTRA_OPTS=--with-pic
or -fPIC
in CFLAGS
etc., works with all GCC 4.0.x on x86 as well and also uses processor-specific settings from MPIR if available.
Updated spkg: http://spkg-upload.googlecode.com/files/ecm-6.3.p2.spkg (same place)
md5sum: 8246ca74be1ee07b312a84d2a88d9142 ecm-6.3.p2.spkg
(fortunately differs ;-) )
pilation on 32-bit x86 processors supporting SSE2. (Also #10252.) (There's only a single, cumulative patch file since both patches are to 'configure.in'.)
[...]
A new MPIR (2.1.3.p2) spkg which handles CFLAGS
better (allowing us to use processor-specific settings chosen by MPIR) is on the way, but will live on another ticket (not #8664). Just haven't committed the changes yet.
New spkg: http://sage.math.washington.edu/home/leif/Sage/spkgs/ecm-6.3.p2.spkg
md5sum:
a19f3d4d0e9881abe076d8a9c0ea7e7f ecm-6.3.p2.spkg
Apply attachment: trac_5847-module_list-fix_execstack-sagelib-rebased_to_4.7.1.alpha4.patch to the Sage library.
(Should be applied after installing the new spkg.)
Note that this patch is only required (i.e., mandatory) on some Fedora and potentially other SELinux-enabled systems, and apparently only in conjunction with more recent versions of GCC (>= 4.6).
I.e., you should be able to use the new GMP-ECM spkg on other systems without installing any patches or other spkgs.
CC: @zimmermann6 @dimpase
Component: packages: standard
Keywords: sd32 MPIR elliptic curves libecm ecm spkg
Author: Mike Hansen, Leif Leonhardy, Jeroen Demeyer
Reviewer: Leif Leonhardy, Dmitrii Pasechnik, Mariah Lenox, Maarten Derickx
Merged: sage-4.7.2.alpha3
Issue created by migration from https://trac.sagemath.org/ticket/5847