I hit the same problem, and changed the configure script of gmp-ecm in line 24196 to read
[code] sprintf (buffer, "%d.%d.%d", __GNU_MP_VERSION, __GNU_MP_VERSION_MINOR, __GNU_MP_VERSION_PATCHLEVEL);[/CODE]
instead of
[code] sprintf (buffer, "%d.%d", __GNU_MP_VERSION, __GNU_MP_VERSION_MINOR);[/code]
After that it compiled.

[QUOTE=M0CZY;169486]I have been trying to compile GMP-ECM using the new GMP-4.3.0 under Linux, but I have hit a snag.

The GMP installs correctly, and passes 'make check', but in the ECM stage, when I get to './configure --with-gmp=/usr/local', it outputs some stuff then finishes with
[code]checking if gmp.h version and libgmp version are the same... (4.3/4.3.0) no
configure: error: 'gmp.h' and 'libgmp' have different versions, you have to reinstall GMP properly.
user@user-desktop:~/ecm-6.2.2$[/code]

I received the same difference in versions when I compiled under Windows using MinGW/Msys, but the program ignored it and continued working.

Could this be a bug in the new version of GMP?[/QUOTE]

Did you try "make install" after "make" and "make check"?

Luigi

[QUOTE=M0CZY;169486]I have been trying to compile GMP-ECM using the new GMP-4.3.0 under Linux, but I have hit a snag.

Could this be a bug in the new version of GMP?[/QUOTE]It's not a bug, it's a mis-feature.

The same change to the GMP version structure has hit the maintainers of a number of other packages similarly. Mail was sent to the GMP developers' list earlier today.

Paul

[quote]Did you try "make install" after "make" and "make check"?[/quote]

Yes.
After 'make' and 'make check', under Ubuntu Linux I did 'sudo make install'
and 'make check' again, and it passed all the tests again.
I understand that it installs by default into /usr/local

Ugh. The new format for the version string (always three parts from now on, including patchlevel even if it's zero) breaks the test. This needs a fix kinda soonish.

Alex

[QUOTE=CRGreathouse;169430]I was more interested in GMP vs MPIR, but that's good to know. 'Word on the street' was that the last versions of GMP and MPIR were about the same speed; will that still hold, or will GMP pull ahead?[/QUOTE]

They are about the same speed, GMP 4.3.0 is slightly faster now on AMD and Core2 than MPIR 1.1. Here are some benchmarks that use some common functions in a loop:

mpz_mul(t, r, r);
mpz_sub_ui(t, t, 2);
mpz_mod(r, t, p);

[CODE]Intel Xeon E5405 @ 2.0GHz (Family 6, Model 23, Stepping 6)
Linux 64bit, gcc version 4.1.2
83338 bits (25088 digits)
Library Time1 Time2
---------- --------- ---------
GMP 4.3.0 2m34.857s 2m34.835s
MPIR 1.1.0 2m58.627s 2m58.706s
MPIR 1.0.0 3m00.482s 3m00.461s
GMP 4.2.4 5m38.156s 5m38.173s

Intel Xeon E5440 @ 2.83GHz (Family 6, Model 23, Stepping 10)
Linux 64bit, gcc version 4.1.2
83338 bits (25088 digits)
Library Time1 Time2
---------- --------- ---------
GMP 4.3.0 1m49.819s 1m49.436s
MPIR 1.1.0 2m05.877s 2m05.959s
MPIR 1.0.0 2m07.519s 2m07.499s
GMP 4.2.4 3m58.960s 3m58.976s

AMD Opteron 248 @ 2.2GHz (Family 15, Model 37, Stepping 1)
Linux 64bit, gcc version 3.4.6
83338 bits (25088 digits)
Library Time1 Time2
---------- --------- ---------
GMP 4.3.0 1m35.091s 1m34.815s
MPIR 1.1.0 1m36.480s 1m35.923s
MPIR 1.0.0 1m37.501s 1m36.857s
GMP 4.2.4 2m56.352s 2m55.702s[/CODE]

Jeff.

Here are some GMP-ECM benchmarks comparing the two on Core2. Since --enable-asm-redc is used, GMP is mostly taken out of the equation anyways.

[CODE]Intel Xeon E5405 @ 2.0GHz (Family 6, Model 23, Stepping 6)
Linux 64bit, gcc version 4.1.2, --enable-asm-redc

ECM
Factoring: 1877138824359859508015524119652506869600959721781289179190693027302028679377371001561
B1=20000000
Sigma: 980060817

MPIR 1.1.0
Step 1 took 61816ms | Step 1 took 61889ms
Step 2 took 27306ms | Step 2 took 27222ms

GMP 4.3.0
Step 1 took 58398ms | Step 1 took 58419ms
Step 2 took 26361ms | Step 2 took 26473ms


P-1
Factoring: 1877138824359859508015524119652506869600959721781289179190693027302028679377371001561
B1=20000000
x0: 524328229

MPIR 1.1.0
Step 1 took 5823ms | Step 1 took 5831ms
Step 2 took 6895ms | Step 2 took 6918ms

GMP 4.3.0
Step 1 took 6012ms | Step 1 took 5999ms
Step 2 took 6904ms | Step 2 took 6886ms


P+1
Factoring: 1877138824359859508015524119652506869600959721781289179190693027302028679377371001561
B1=20000000
x0: 524328229

MPIR 1.1.0
Step 1 took 12413ms | Step 1 took 12354ms
Step 2 took 10254ms | Step 2 took 10236ms

GMP 4.3.0
Step 1 took 11844ms | Step 1 took 12221ms
Step 2 took 10294ms | Step 2 took 10259ms
[/CODE]

An rc for 6.2.3 is at
[url]http://www.loria.fr/~kruppaal/ecm-6.2.3d.tar.gz[/url]

From NEWS:
[CODE]
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 suitable architectures
[/code]

The config.guess/config.sub scripts of autotools were updated, too... I hope this didn't break too much. Tests on different platforms, especially MinGW, MSVC, and Mac would be welcome.

Alex

[QUOTE=akruppa;169797]The config.guess/config.sub scripts of autotools were updated, too... I hope this didn't break too much. Tests on different platforms, especially MinGW, MSVC, and Mac would be welcome.[/QUOTE]

I have only had a chance to try it on cygwin on a Q9550 Core2 but for some reason configure thinks it is a pentium3 so I don't get any SSE2 code.

Jeff.

What does uname -m say? If that returns, e.g., i686 as the cpu type, then configure uses Pentium3 code by default. You could override that with configure --build=i786.

Alex

[quote=akruppa;169797]* Fixed bug which caused only one ECM curve to be run in spite of -c parameter if input line did not end in newline[/quote]

:bow: