search

sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.41k stars 475 forks source link

Update GMP-ECM to 6.3 #5847

Closed 85eec1a4-3d04-4b4d-b711-d4db03337c41 closed 13 years ago

85eec1a4-3d04-4b4d-b711-d4db03337c41 commented 15 years ago 
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 
  (and presumably other systems)
* Allow use of x86_64 asm code under MinGW

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
  could lead to incorrect arithmetic in rare cases
* Fixed memory leak with -v parameter when factor was found in ECM stage 1
* Fixed bug which caused only one ECM curve to be run in spite of -c
  parameter if input line did not end in newline
* Assembler mulredc code enabled by default on x86_64

Changes between ecm-6.2.1 and ecm-6.2.2:
* Updated build project files for Visual C by Brian Gladman, also adds
missing NTT_GFP_TWIDDLE_DI[FT]_BREAKOVER defines in VC parameter file
* Fixed uninitialised parameter to P-1 probability computation
* In tune.c : fixed generation of NTT_GFP_TWIDDLE_DI[FT]_BREAKOVER values,
avoid calling cputime() excessively often when timing short functions,
fixed access to uninitialised memory
* Fixed serious split infinitive in configure script (thanks Paul Leyland)
* Removed unnecessary carry propagation in x86_64 mulredc code, slight
speedup (thanks Philip McLaughlin)
* Fixed non-portable PIC code in x86_64/redc.asm
* Fixed problem with pattern matching host type names in configure.in
* Converted binary constants in spv.c and ntt_gfp.c to hexadecimal,
some assembler do not support binary constants

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

zimmermann6 commented 13 years ago
comment:44

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

dimpase commented 13 years ago
comment:45

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

jdemeyer commented 13 years ago
comment:46

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
zimmermann6 commented 13 years ago
comment:47

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

dimpase commented 13 years ago
comment:48

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

dimpase commented 13 years ago
comment:49

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

dimpase commented 13 years ago
comment:50

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.

zimmermann6 commented 13 years ago
comment:51

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

jdemeyer commented 13 years ago
comment:52

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)

dimpase commented 13 years ago
comment:53

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

jdemeyer commented 13 years ago

Changed author from Mike Hansen, Leif Leonhardy to Mike Hansen, Leif Leonhardy, Jeroen Demeyer

jdemeyer commented 13 years ago
comment:54

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.

jdemeyer commented 13 years ago

Changed work issues from include patch for 32-bit ppc to none

jdemeyer commented 13 years ago

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

jdemeyer commented 13 years ago

patch from p0 to p1, for review

jdemeyer commented 13 years ago
comment:55

Attachment: ecm-6.3.p1.patch.gz

jdemeyer commented 13 years ago

Merged: sage-4.6.1.alpha1

jdemeyer commented 13 years ago
comment:56

Tested new spkg succesfully on the previously-failing OS X 10.4 PPC machine.

dimpase commented 13 years ago

Changed reviewer from Leif Leonhardy to Leif Leonhardy, Dima Pasechnik

dimpase commented 13 years ago
comment:57

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!

jdemeyer commented 13 years ago
comment:59

There is some serious trouble with this spkg: #10252

jdemeyer commented 13 years ago

Changed merged from sage-4.6.1.alpha1 to none

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:62

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.)

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:63

New spkg: http://spkg-upload.googlecode.com/files/ecm-6.3.p2.spkg

md5sum: 85eabecaa8974a270d5587ef8de06da1 ecm-6.3.p2.spkg

ecm-6.3.p2 (Leif Leonhardy, November 23rd, 2010)

Special Update/Build Instructions

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.)

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

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 +

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:64

FWIW, you can also test this package with the old MPIR (1.2.2), or some older GMP. Should work as well.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:65

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

(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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:66

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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:67

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.

zimmermann6 commented 13 years ago
comment:68

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

jdemeyer commented 13 years ago
comment:69

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.

jdemeyer commented 13 years ago
comment:70

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
jdemeyer commented 13 years ago
comment:71

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
jdemeyer commented 13 years ago

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)

 ---
83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:73

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...

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:74

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?

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:75

P.S.: As I said, I first want to get some test results (e.g. on PowerPCs etc.) before I upload further changes.

jdemeyer commented 13 years ago
comment:76

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).

jdemeyer commented 13 years ago
comment:77

Replying to @nexttime:

Do you read the comments?

Clearly, I did not...

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:78

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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:79

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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:80

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.

jdemeyer commented 13 years ago
comment:81

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:82

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... ;-)

jdemeyer commented 13 years ago
comment:83

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.

jdemeyer commented 13 years ago
comment:84

I'm still thinking that these changes should go to the mpir package and that ecm should use the default CFLAGS provided by mpir.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:85

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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

Changed keywords from none to MPIR elliptic curves libecm

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:86

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 ;-) )

ecm-6.3.p2 (Leif Leonhardy, November 25th, 2010)

Special Update/Build Instructions

[...]

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.