Opened 13 years ago
Last modified 10 years ago
#5847 closed enhancement
Update GMP-ECM to 6.3 — at Version 54
Reported by: | mabshoff | Owned by: | leif |
---|---|---|---|
Priority: | major | Milestone: | sage-4.7.2 |
Component: | packages: standard | Keywords: | sd32 MPIR elliptic curves libecm ecm spkg |
Cc: | zimmerma, dimpase | Merged in: | |
Authors: | Mike Hansen, Leif Leonhardy, Jeroen Demeyer | Reviewers: | Leif Leonhardy |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
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/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
Change History (60)
comment:2 Changed 12 years ago by
- Summary changed from Update GMP-ECM to 6.2.2 to Update GMP-ECM to 6.3
comment:3 Changed 12 years ago by
- Status changed from new to needs_review
There is a 6.3 spkg at http://sage.math.washington.edu/home/mhansen/ecm-6.3.spkg
I've checked that it works with MPIR 2.1.1 and all tests pass.
comment:4 Changed 12 years ago by
Since Sage with MPIR 2.1.1 (#8664) requires updating to this package, I report at that ticket.
comment:5 Changed 12 years ago by
Since MPIR 2.1.1 has a bug (see #9837), I've (successfully) built and tested Sage 4.6.prealpha3 (see #9343 and the NewPARI Wiki page) with GMP 5.0.1 and this new ECM 6.3 spkg on Ubuntu 10.04 x86_64 (Core2, gcc 4.4.3; parallel build from scratch with 32 jobs; native code with O3).
ptestlong
passed all tests.
comment:6 Changed 12 years ago by
It also passed ptestlong
on the same machine with Sage 4.5.3.alpha2 and MPIR 2.1.1 (because the MPIR bug apparently only shows up in combination with the new PARI package, which isn't included in that Sage version).
Same for Fedora 13 x86 (Pentium 4 Prescott, gcc 4.4.4, parallel build with 6 jobs, rest dito).
Changed 12 years ago by
Suggested changes - NOT (yet) a Mercurial patch. (Minor fixes, some comments added, some clean-up.)
comment:7 Changed 12 years ago by
I've added a reviewer patch (ordinary context diff) with some changes:
- Remove also the manual page of previous installations.
- Typo:
rm -r
->rm -f
(header file) - Removed setting of
CXXFLAGS
, since we don't have C++ code. - Don't overwrite
CFLAGS
ifSAGE64=yes
(instead, append). Removed-O2 -g
in that case. Make use ofCFLAG64
if set. - Quote
$SAGE_LOCAL
in the parameters toconfigure
, too. - Use
$MAKE
inspkg-check
, too. - Some messages changed (e.g. all failures now starting with "Error"), some added.
- A few comments/notes added (
SPKG.txt
,spkg-install
).
If you're ok with the changes, I can replace the diff with a Mercurial patch. Or simply merge them...
comment:8 Changed 12 years ago by
- Reviewers set to Leif Leonhardy
- Type changed from defect to enhancement
New spkg: http://spkg-upload.googlecode.com/files/ecm-6.3.p0.spkg
md5sum: b9b1fcd5ebc2e3689fd379c1dba3a372 ecm-6.3.p0.spkg
New spkg based on Mike's with some more changes (than mentioned above).
Should be installed with the MPIR 2.1.3 spkg from #8664. See instructions there.
(Tested with Sage 4.6.1.alpha0 on Ubuntu 9.04 x86 and Ubuntu 10.04 x86_64.)
Changed 12 years ago by
SPKG "reviewer" patch, based on Mike's, i.e. ecm-6.3 vs. ecm-6.3.p0. For reference/review.
comment:9 Changed 12 years ago by
Built and tested on sage.math.washington.edu without problems.
comment:10 Changed 12 years ago by
- Owner changed from mabshoff to leif
comment:11 Changed 12 years ago by
This fails to compile on my OS X 10.4 powerpc G5 machine, full log attached but here is the interesting part:
**************************************************** Host system uname -a: Darwin moufang.ugent.be 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc **************************************************** **************************************************** CC Version gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man -- enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with- slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5367) **************************************************** ... checking build system type... powerpc-apple-darwin8.11.0 checking host system type... powerpc-apple-darwin8.11.0 ... configure: Configuration: configure: Build for host type powerpc-apple-darwin8.11.0 configure: CC=gcc, CFLAGS=-g -O3 -fPIC configure: Linking GMP with -lgmp configure: Using asm redc code from directory powerpc64 configure: Not using SSE2 instructions in NTT code configure: Assertions disabled configure: Shell command execution disabled configure: OpenMP disabled configure: Memory debugging disabled make all-recursive Making all in powerpc64 m4 -I../ -DOPERATION_mulredc1 `test -f mulredc1.asm || echo './'`mulredc1.asm >mulredc1.s /bin/sh ../libtool --mode=compile gcc -g -O3 -fPIC -c -o mulredc1.lo mulredc1.s libtool: compile: gcc -g -O3 -fPIC -c mulredc1.s -o mulredc1.o mulredc1.s:40:mulld instruction is only for 64-bit implementations (not allowed without -force_cpusubtype_ALL option) mulredc1.s:41:mulhdu instruction is only for 64-bit implementations (not allowed without -force_cpusubtype_ALL option) mulredc1.s:42:mulld instruction is only for 64-bit implementations (not allowed without -force_cpusubtype_ALL option) mulredc1.s:43:mulld instruction is only for 64-bit implementations (not allowed without -force_cpusubtype_ALL option) mulredc1.s:44:mulhdu instruction is only for 64-bit implementations (not allowed without -force_cpusubtype_ALL option) mulredc1.s:47:std instruction is only for 64-bit implementations (not allowed without -force_cpusubtype_ALL option) make[4]: *** [mulredc1.lo] Error 1 rm mulredc1.s make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 Error building GMP-ECM.
comment:12 Changed 12 years ago by
- Description modified (diff)
comment:13 follow-up: ↓ 16 Changed 12 years ago by
Well, I think these are the relevant parts:
... checking whether we can link against GMP... yes checking if gmp.h version and libgmp version are the same... (5.0.1/5.0.1) yes checking for __gmpn_add_nc... yes checking for __gmpn_mod_34lsub1... yes checking for __gmpn_redc_1... no ... configure: Using asm redc code from directory powerpc64 ...
So it's probably an upstream problem, either MPIR or ECM.
Or should we pass -force_cpusubtype_ALL
? (To the assembler?) I think rather not.
What happens on other PPCs?
Can you try installing it with GMP 5.0.1?
comment:14 follow-up: ↓ 17 Changed 12 years ago by
- Cc zimmerma added
Paul, perhaps you have an idea what's going wrong there (ECM trying to use "64-bit" instructions on MacOS X 10.4 PPC [G5], with MPIR 2.1.3).
comment:15 follow-ups: ↓ 18 ↓ 26 Changed 12 years ago by
Jeroen, can you try configuring with --disable-asm-redc
?
(The 64-bit PPC asm code is new in 6.3 btw.)
comment:16 in reply to: ↑ 13 ; follow-up: ↓ 20 Changed 12 years ago by
Replying to leif:
Well, I think these are the relevant parts:
... checking whether we can link against GMP... yes checking if gmp.h version and libgmp version are the same... (5.0.1/5.0.1) yes checking for __gmpn_add_nc... yes checking for __gmpn_mod_34lsub1... yes checking for __gmpn_redc_1... no ... configure: Using asm redc code from directory powerpc64 ...So it's probably an upstream problem, either MPIR or ECM.
Or should we pass
-force_cpusubtype_ALL
? (To the assembler?) I think rather not.What happens on other PPCs?
Can you try installing it with GMP 5.0.1?
A remark about installing with GMP 5. On Gentoo I had to apply the following for it to compile
# fixes for gmp-5 sed -i "s:__GMP_BITS_PER_MP_LIMB:GMP_LIMB_BITS:g" bestd.c mpmod.c \ schoen_strass.c sp.h || die "failed to patch files for gmp-5"
This is backward compatible with GMP 4.3. I am a bit surprised that with the stuff that mpir has deprecated, they didn't deprecate that as well.
comment:17 in reply to: ↑ 14 Changed 12 years ago by
Replying to leif:
Paul, perhaps you have an idea what's going wrong there (ECM trying to use "64-bit" instructions on MacOS X 10.4 PPC [G5], with MPIR 2.1.3).
is this a 32-bit machine? What does ECM config.guess return? Can you try the svn version of
GMP-ECM using svn checkout svn://scm.gforge.inria.fr/svn/ecm
?
Paul
comment:18 in reply to: ↑ 15 ; follow-up: ↓ 21 Changed 12 years ago by
Replying to leif:
Jeroen, can you try configuring with
--disable-asm-redc
?(The 64-bit PPC asm code is new in 6.3 btw.)
it should work with --disable-asm-redc
.
Paul
comment:19 Changed 12 years ago by
Thanks for all the suggestions, I will try them but probably not today.
comment:20 in reply to: ↑ 16 Changed 12 years ago by
Replying to fbissey:
Replying to leif:
Can you try installing it with GMP 5.0.1?
A remark about installing with GMP 5. On Gentoo I had to apply the following for it to compile
# fixes for gmp-5 sed -i "s:__GMP_BITS_PER_MP_LIMB:GMP_LIMB_BITS:g" bestd.c mpmod.c \ schoen_strass.c sp.h || die "failed to patch files for gmp-5"
This is backward compatible with GMP 4.3. I am a bit surprised that with the stuff that mpir has deprecated, they didn't deprecate that as well.
Worked for me without patching with both MPIR 2.1.1 and [vanilla] GMP 5.0.1 on Ubuntu (see above).
comment:21 in reply to: ↑ 18 ; follow-up: ↓ 25 Changed 12 years ago by
- Cc dimpase added
Replying to zimmerma:
Replying to leif:
Jeroen, can you try configuring with
--disable-asm-redc
?(The 64-bit PPC asm code is new in 6.3 btw.)
it should work with
--disable-asm-redc
.
Thanks!
Replying to jdemeyer:
Thanks for all the suggestions, I will try them but probably not today.
Should I update the spkg / spkg patch to enable --disable-asm-redc
(on MacOS X PPC 10.4 and perhaps 10.5, or simply PPC)?
IIRC we don't support 64-bit builds (SAGE64=yes
) on PowerPC (and MacOS X < 10.6) anyway, and Apple doesn't support MacOS X 10.6 on PPCs.
Setting ABI=32
would perhaps also work.
comment:22 Changed 12 years ago by
Any objections to enable (also) building a shared library?
(And also enabling the build of a static MPIR library, which is better for ECM?)
comment:23 follow-up: ↓ 29 Changed 12 years ago by
I wonder how the GNU assembler (Linux PPC) behaves...
François, would you like to test this?
comment:24 follow-up: ↓ 53 Changed 12 years ago by
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:
--- configure.in (revision 1515) +++ configure.in (revision 1516) @@ -195,7 +195,7 @@ # asm_redc enabled by default for x86_64 and 64 bit PowerPC if test "x$enable_asm_redc" = x; then case $host in - x86_64* | powerpc-apple-darwin* | powerpc64-*-linux*) enable_asm_redc=yes;; + x86_64*-*-* | powerpc-apple-darwin* | powerpc64-*-linux*) enable_asm_redc=yes;; *) enable_asm_redc=no;; esac fi @@ -203,8 +203,18 @@ if test "x$enable_asm_redc" = xyes; then case $host in pentium4-*-* | pentium3-*-* | viac7-*-* | i786-*-*) ASMPATH=pentium4;; - x86_64-*-*) ASMPATH=x86_64;; - powerpc-apple-darwin*) ASMPATH=powerpc64;; + x86_64*-*-*) ASMPATH=x86_64;; +# warning: with powerpc-apple-darwin* we can have ABI=32 +# see bug #10646 on the bug tracker, where config.guess says +# powerpc-apple-darwin8.11.0 (this a 64-bit machine, but most applications +# are compiled in 32 bits). It works with --disable-asm-redc. + powerpc-apple-darwin*) +AC_PREPROC_IFELSE([AC_LANG_PROGRAM([ +#if defined(__ppc__) +#error +#endif])], [], [AC_MSG_NOTICE([32-bit PowerPC, disabling asm-redc]) + enable_asm_redc=no]) + ASMPATH=powerpc64;; powerpc64-*-linux*) ECM_INCLUDE([<"$srcdir"/powerpc64/powerpc-defs.m4>]) ASMPATH=powerpc64;; @@ -213,7 +223,9 @@ ASMPATH=athlon;; *) AC_MSG_ERROR([[asm redc not available on this machine $host]]);; esac +fi +if test "x$enable_asm_redc" = xyes; then # do the necessary definitions and includes AC_DEFINE([NATIVE_REDC],1,[Define to 1 to use asm redc]) test "x$CCAS" != x || CCAS="$CC -c"
Please can you check it works correctly with this patch?
Paul
comment:25 in reply to: ↑ 21 Changed 12 years ago by
comment:26 in reply to: ↑ 15 ; follow-up: ↓ 27 Changed 12 years ago by
- Status changed from needs_review to needs_work
- Work issues set to include patch for 32-bit ppc
Replying to leif:
Jeroen, can you try configuring with
--disable-asm-redc
?
The build (outside of Sage) works.
Replying to zimmerma:
is this a 32-bit machine?
Well, technically the processor is 64-bit capable (I believe) but it runs a 32-bit system and gcc
produces 32-bit code by default.
What does ECM config.guess return?
powerpc-apple-darwin8.11.0
Can you try the svn version of
GMP-ECM using
svn checkout svn://scm.gforge.inria.fr/svn/ecm
?
This works.
Replying to zimmerma:
in fact this bug is already fixed upstream (in revision 1516)
Please can you check it works correctly with this patch?
This works.
Replying to leif:
Setting
ABI=32
would perhaps also work.
No, it does not.
comment:27 in reply to: ↑ 26 ; follow-up: ↓ 52 Changed 12 years ago by
Replying to jdemeyer:
Replying to leif:
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).
I think passing -Wa,-force_cpusubtype_ALL
on MacOS PPCs should also work (which does not disable the assembly code, but avoids the odd assembler error, such that we get better performance).
Note that this worked on Dima's G4 with MPIR, so I expect it to work with a G5, too.
Don't know if G3s run into the same problem, or support these instructions. We then might have to really disable the code on PPCs < G4.
We could of course just test this in spkg-install
, i.e. feed some extended instruction set assembly code to the assembler with -force_cpusubtype_ALL
and see if we get an error before we disable the redc asm code. (I'd have to look what option gas
takes on Linux PPC.)
Objections against adding yet another environment variable (ECM_EXTRA_OPTS
, to add to ECM's configure
, analoguous to PARI_EXTRA_OPTS
), to ease working around potential problems showing up later?
comment:28 Changed 12 years ago by
- Status changed from needs_work to needs_info
From my gas
manpage (relevant for Linux PPC only):
... Target PowerPC options: [-mpwrx|-mpwr2|-mpwr|-m601|-mppc|-mppc32|-m603|-m604| -m403|-m405|-mppc64|-m620|-mppc64bridge|-mbooke] [-mcom|-many|-maltivec|-mvsx] [-memb] [-mregnames|-mno-regnames] [-mrelocatable|-mrelocatable-lib] [-mlittle|-mlittle-endian|-mbig|-mbig-endian] [-msolaris|-mno-solaris] ...
The options for other architectures in addition have more detailed descriptions, but unfortunately not the ones for PPC as the target. But it seems gas
enables instruction set extensions by default.
P.S.: That the build works with -force_cpusubtype_ALL
(without SAGE_CHECK=yes
) doesn't necessarily mean we couldn't get illegal instruction exceptions when actually running the code.
comment:29 in reply to: ↑ 23 ; follow-up: ↓ 30 Changed 12 years ago by
Replying to leif:
I wonder how the GNU assembler (Linux PPC) behaves...
François, would you like to test this?
I know that gmp-ecm-6.3 builds on my linux ppc system but I don't believe I have the assembler enabled. I will try that as soon as I have access to the machine next week. I will also have a look at mpir. Note that my test machine is a G4.
I am a bit surprised that no changes where needed to build it against GMP 5.0.1 I add a bug report specifically on that in Gentoo and I could reproduce it on one of my machine which has GMP 5.0.1.
comment:30 in reply to: ↑ 29 ; follow-up: ↓ 31 Changed 12 years ago by
Replying to fbissey:
Replying to leif:
I wonder how the GNU assembler (Linux PPC) behaves...
François, would you like to test this?
I know that gmp-ecm-6.3 builds on my linux ppc system but I don't believe I have the assembler enabled. I will try that as soon as I have access to the machine next week. I will also have a look at mpir. Note that my test machine is a G4.
Ok.
I am a bit surprised that no changes where needed to build it against GMP 5.0.1
Hmmm, we have to upgrade ECM because of the upgrade of MPIR / GMP:
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
I add a bug report specifically on that in Gentoo and I could reproduce it on one of my machine which has GMP 5.0.1.
comment:31 in reply to: ↑ 30 Changed 12 years ago by
Replying to leif:
Replying to fbissey:
Replying to leif:
I wonder how the GNU assembler (Linux PPC) behaves...
François, would you like to test this?
I know that gmp-ecm-6.3 builds on my linux ppc system but I don't believe I have the assembler enabled. I will try that as soon as I have access to the machine next week. I will also have a look at mpir. Note that my test machine is a G4.
Ok.
I am a bit surprised that no changes where needed to build it against GMP 5.0.1
Hmmm, we have to upgrade ECM because of the upgrade of MPIR / GMP:
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
I remember adding 6.3 to the sage-on-gentoo tree for GMP-5 {{{# ChangeLog? for sci-mathematics/ecm # Copyright 1999-2010 Gentoo Foundation; Distributed under the GPL v2 # $Header: $
08 Sep 2010; François Bissey <f.r.bissey@…> metadata.xml: fix metadata
03 Aug 2010; Christopher Schwan <cschwan@…> -ecm-6.2.3.ebuild, -ecm-6.3.ebuild: Removed old versions
*ecm-6.3-r1 (23 Jul 2010)
23 Jul 2010; Christopher Schwan <cschwan@…> +ecm-6.3-r1.ebuild: Migrated to autotools-utils.eclass
08 Jul 2010; François Bissey <f.r.bissey@…> ecm-6.3.ebuild: Hopefully fixed for gmp-5
*ecm-6.3 (07 Jul 2010)
07 Jul 2010; François Bissey <f.r.bissey@…> +ecm-6.3.ebuild: Version bump. Hopefully helpfull with gmp-5.
}}} I'll have to check my inbox for the details. I imported it on the 7th of July because it said it was compatible with GMP-5 and one of our user was using that. The user then reported that he still couldn't get ECM to build and I introduced the fix above the next day which solved the problem. A possibility is interference with by a patch to GMP Gentoo side.
On a positive note ECM 6.3 is the default in sage-on-gentoo since the 3rd of August so it has been extensively tested on x86, amd64 and ppc. However assembler code is at the user's discretion.
comment:32 follow-up: ↓ 33 Changed 12 years ago by
- Status changed from needs_info to needs_work
on MacOSX 10.5 PPC (G4) I get
checking what assembly label suffix to use... : checking if globals are prefixed by underscore... configure: error: Test program links neither with nor without underscore. Error configuring GMP-ECM.
$ gcc -v
Using built-in specs. Target: powerpc-apple-darwin9 Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure --disable-checking --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/[cg][.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5577)
comment:33 in reply to: ↑ 32 ; follow-up: ↓ 35 Changed 12 years ago by
Replying to dimpase:
on MacOSX 10.5 PPC (G4) I get
checking what assembly label suffix to use... : checking if globals are prefixed by underscore... configure: error: Test program links neither with nor without underscore. Error configuring GMP-ECM.
Can you attach the config.log
?
(Maybe weird CFLAGS
etc. settings in your environment?)
comment:34 Changed 12 years ago by
- Status changed from needs_work to needs_info
comment:35 in reply to: ↑ 33 ; follow-ups: ↓ 36 ↓ 39 Changed 12 years ago by
Replying to leif:
Replying to dimpase:
on MacOSX 10.5 PPC (G4) I get
checking what assembly label suffix to use... : checking if globals are prefixed by underscore... configure: error: Test program links neither with nor without underscore. Error configuring GMP-ECM.
Can you attach the
config.log
?
done
(Maybe weird
CFLAGS
etc. settings in your environment?)
no, it's rather prosaic
$ gcc -g conftes1.o conftes2.o collect2: ld terminated with signal 10 [Bus error] ld warning: can't find atom for stabs FUN at 00000000 in conftes2.o
comment:36 in reply to: ↑ 35 ; follow-up: ↓ 37 Changed 12 years ago by
Replying to dimpase:
$ gcc -g conftes1.o conftes2.o collect2: ld terminated with signal 10 [Bus error] ld warning: can't find atom for stabs FUN at 00000000 in conftes2.o
more details - it looks like "-g" flag does not work here:
$ cat conftes1.c #ifdef __cplusplus extern "C" { void underscore_test(); } #endif main () { underscore_test(); } $ $ cat conftes2.s .text .globl _underscore_test _underscore_test: $ $ gcc -g -o x conftes1.c conftes2.s collect2: ld terminated with signal 10 [Bus error] ld warning: can't find atom for stabs FUN at 00000000 in /var/folders/wg/wghOV5z8H7Ox9E0VSGnzm++++TM/-Tmp-//cc5M42pV.o $ gcc -o x conftes1.c conftes2.s $ ./x $
could it be due to "empty" conftes2.s ?
comment:37 in reply to: ↑ 36 ; follow-up: ↓ 38 Changed 12 years ago by
- Status changed from needs_info to needs_work
Replying to dimpase:
more details - it looks like "-g" flag does not work here:
$ cat conftes1.c #ifdef __cplusplus extern "C" { void underscore_test(); } #endif main () { underscore_test(); } $ $ cat conftes2.s .text .globl _underscore_test _underscore_test: $ $ gcc -g -o x conftes1.c conftes2.s collect2: ld terminated with signal 10 [Bus error] ld warning: can't find atom for stabs FUN at 00000000 in /var/folders/wg/wghOV5z8H7Ox9E0VSGnzm++++TM/-Tmp-//cc5M42pV.o $ gcc -o x conftes1.c conftes2.s $ ./x $
could it be due to "empty" conftes2.s ?
Indeed:
$ cat c2.s .text .globl _underscore_test _underscore_test: mflr r0 $ gcc -g -o x conftes1.c c2.s $ ./x $ gcc -g -O2 -o x conftes1.c c2.s $ ./x $ gcc -o x conftes1.c c2.s $ ./x $
So, one (not me :-( )needs to explain this to the autoconf, I suppose
comment:38 in reply to: ↑ 37 Changed 12 years ago by
Replying to dimpase:
So, one (not me :-( )needs to explain this to the autoconf, I suppose
I went ahead and tweaked configure with the extra asm command in conftes2.s above. It passes, but then I get it misconfigured to ppc64, and then make does not work, as it wants to build ppc64-specific asm code. The following does it better:
$ ./configure --disable-asm-redc
with this, both make and make check work OK. This is all so far out of Sage tree. I'll attach config.log, just in case.
Changed 12 years ago by
macosx 10.5 ppc G4 with tweaked ./configure --disable-asm-redc (adding extra command in conftes2.s)
comment:39 in reply to: ↑ 35 Changed 12 years ago by
Replying to dimpase:
no, it's rather prosaic
$ gcc -g conftes1.o conftes2.o collect2: ld terminated with signal 10 [Bus error] ld warning: can't find atom for stabs FUN at 00000000 in conftes2.o
Please do $ /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/ld --version $ which ld $ ld --version
comment:40 follow-up: ↓ 42 Changed 12 years ago by
Again, with proper formatting:
$ /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/ld --version $ which ld $ ld --version
comment:41 follow-up: ↓ 43 Changed 12 years ago by
[I write here as a developer of GMP-ECM]
the configure error reported in comment 32 seems to be a ld problem. User "dimpase", do you manage to configure GMP successfully?
Also, which version of GMP-ECM did you use in comment 32? The svn version (see comment 24) should fix the fact that 64-bit assembly is used on 32-bit machines. If not, please report the problem upstream on http://ecm.gforge.inria.fr/.
Paul Zimmermann
comment:42 in reply to: ↑ 40 Changed 12 years ago by
Replying to jdemeyer:
$ /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/ld -v @(#)PROGRAM:ld PROJECT:ld64-85.2.1 $ ld -v @(#)PROGRAM:ld PROJECT:ld64-85.2.1 $ which ld /usr/bin/ld
I think it's the latest ld available under Xcode for ppc. (Same for gcc-4.0.1)
comment:43 in reply to: ↑ 41 Changed 12 years ago by
Replying to zimmerma:
[I write here as a developer of GMP-ECM]
the configure error reported in comment 32 seems to be a ld problem. User "dimpase", do you manage to configure GMP successfully?
Yes, I do. MPIR, to be more precise. The version on #8664.
Also, which version of GMP-ECM did you use in comment 32?
the one packed in the spkg on this ticket.
Subsequent experiments were made on the same version (without whatever patches in the spkg, however).
I then packaged the configure fix and the extra config flag into Sage spkg and am building Sage using it and the MPIR spkg on #8664. (it's not done yet, this machine is slooooow...)
The svn version (see comment 24) should fix the fact that 64-bit assembly is used on 32-bit machines. If not, please report the problem upstream on http://ecm.gforge.inria.fr/.
do you want me to test the svn version on this machine?
Paul Zimmermann
Dima Pasechnik
comment:44 follow-up: ↓ 45 Changed 12 years ago by
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
comment:45 in reply to: ↑ 44 ; follow-ups: ↓ 46 ↓ 48 Changed 12 years ago by
Replying to zimmerma:
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
comment:46 in reply to: ↑ 45 ; follow-up: ↓ 50 Changed 12 years ago by
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
comment:47 follow-up: ↓ 49 Changed 12 years ago by
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
comment:48 in reply to: ↑ 45 Changed 12 years ago by
Replying to dimpase:
Replying to zimmerma:
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
comment:49 in reply to: ↑ 47 ; follow-up: ↓ 51 Changed 12 years ago by
Replying to zimmerma:
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
comment:50 in reply to: ↑ 46 Changed 12 years ago by
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.
comment:51 in reply to: ↑ 49 Changed 12 years ago by
Replying to dimpase:
Replying to zimmerma:
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
comment:52 in reply to: ↑ 27 Changed 12 years ago by
Replying to leif:
Replying to jdemeyer:
Replying to leif:
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)
comment:53 in reply to: ↑ 24 Changed 12 years ago by
Replying to zimmerma:
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
comment:54 Changed 12 years ago by
- Description modified (diff)
- Status changed from needs_work to needs_review
- Work issues include patch for 32-bit ppc deleted
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.