[QUOTE=EdH;274174]Well, I tried make clean again and this time it did delete them. Maybe I didn't do clean in that directory last time on my way up toward trunk trying each level.

Anyway, It made it further, but I still get an error:
[code]
cc -O3 -march=k8 -mtune=k8 -funroll-loops -I. -I./asm -L. -o gnfs-lasieve4I11e gnfs-lasieve4eI11.o if.o input-poly.o redu2.o recurrence6.o fbgen.o real-poly-aux.o primgen32.o lasieve-prepn.o mpqs.o libgmp-aux.a liblasieve.a liblasieveI11.a -lgmp-aux -lgmp -lm -static
/usr/bin/ld: cannot find -lgmp
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [gnfs-lasieve4I11e] Error 1
[/code]On top of that, for some odd reason, I can no longer get a complete download from the repository. I tried to do a purely clean checkout several times and they lock it up so I have to delete the folder to try again. I have a couple copies I'm trying things with, but expected to start from scratch. Oh well, sorry to be a pain again. It must be me... I don't hear of any others having these difficulties.:sad:[/QUOTE]

No worries, everyone has had trouble compiling ggnfs at one point or another. Although I'm confused by the most recent error. The linker is saying it can't find libm and libc, which I had always thought were standard libraries in any linux installation. I'm not sure what the best way is to go about installing them on your system - can anyone else help here? It might help to know exactly which distribution you are using.

Oh, and you also need to build and install [URL="http://gmplib.org/"]gmp[/URL].

[QUOTE=bsquared;274185]No worries, everyone has had trouble compiling ggnfs at one point or another. Although I'm confused by the most recent error. The linker is saying it can't find libm and libc, which I had always thought were standard libraries in any linux installation. I'm not sure what the best way is to go about installing them on your system - can anyone else help here? It might help to know exactly which distribution you are using.

Oh, and you also need to build and install [URL="http://gmplib.org/"]gmp[/URL].[/QUOTE]
Well, this is a fresh installation of Fedora 15 64-bit on a dual-core Athlon64 CPU machine. I have installed all the Fedora repository gmp-ecm packages. There were a couple files I install on my Ubuntu 32-bit distributions that I could not find when I installed Fedora 64-bit. In fact, one of them was libecm-dev. I "assumed" gmp-ecm-devel was the equivalent, but that apparently is not the case. This distribution does not show me any libecm.:sad:

The three files installed:
[code]
-gmp-ecm-6.3-1.fc15 (x86_64)
-gmp-ecm-devel-6.3-1.fc15 (x86_64)
-gmp-ecm-static-6.3-1.fc15 (x86_64)
[/code]I just downloaded gmp-5.0.2, compiled and installed it.

Perhaps some progress:
[code]
cc -O3 -march=k8 -mtune=k8 -funroll-loops -I. -I./asm -L. -o gnfs-lasieve4I11e gnfs-lasieve4eI11.o if.o input-poly.o redu2.o recurrence6.o fbgen.o real-poly-aux.o primgen32.o lasieve-prepn.o mpqs.o libgmp-aux.a liblasieve.a liblasieveI11.a -lgmp-aux -lgmp -lm -static
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [gnfs-lasieve4I11e] Error 1
[/code]the line:
[code]
/usr/bin/ld: cannot find -lgmp
[/code]is no longer there...

Yep, progress with the gmp install. For the other libraries, libecm is not the problem. Apparently you are missing libm, the math library with stuff like sqrt in it, and libc, which is another basic library. So basic, that I don't know what rpm package they would be in. glibc, maybe? It's late, so I punt.

Yeah, for -lc and -lm, I'd say that you need the -devel packages related to glibc.

Your system will definitely have libm, but you may have to be explicit about linking it in on the gcc command line (add '-lm' to it).

yum install glibc-static

Thanks to everyone that's helping.

@bsquared: I forgot to mention that I used:
[code]
ln -s athlon64 asm
[/code]When I tried asm/ it gave me:
[code]
ln: target `asm/' is not a directory: No such file or directory
[/code]@fivemack: I installed glibc-static. I also saw a glibc-utils (Development utilities from GNU C library) was not installed. I still didn't install that one.

I was able to get a clean copy from sourceforge today. It says version 416. Maybe the updating was why I couldn't get it last night.

This time I came up with a conflict error:
[code]
cc -O3 -march=k8 -mtune=k8 -funroll-loops -I. -I./asm -c -DI_bits=11 -o gnfs-lasieve4eI11.o gnfs-lasieve4e.c
In file included from gnfs-lasieve4e.c:51:0:
gmp-aux.w:17:6: error: conflicting types for ‘__gmpz_mul_si’
/usr/local/include/gmp.h:995:21: note: previous declaration of ‘__gmpz_mul_si’ was here
make: *** [gnfs-lasieve4eI11.o] Error 1
[/code]I also gave make x86_64 in trunk another shot and received the same error:
[code]
gmp-aux.c:60:6: error: conflicting types for ‘__gmpz_mul_si’
/usr/local/include/gmp.h:995:21: note: previous declaration of ‘__gmpz_mul_si’ was here
make[3]: *** [gmp-aux.o] Error 1
make[3]: Leaving directory `/home/duser/Math/ggnfs/trunk/src/lasieve4'
make[2]: *** [latsiever] Error 2
make[2]: Leaving directory `/home/duser/Math/ggnfs/trunk/src'
make[1]: *** [common] Error 2
make[1]: Leaving directory `/home/duser/Math/ggnfs/trunk'
make: *** [x86_64] Error 2
[/code]Thanks again, everyone.

I had hopes of creating a web page of how I installed all of this to Fedora 64-bit, like the one I did for Ubuntu (32-bit), but It sure is looking complicated and will be "fun" to sort out what finally is needed.

I got that error myself recently. The "conflicting types for __gmpz_mul_si" error is because of the
[code]#if __GNU_MP_VERSION < 3 || __GNU_MP_VERSION_MINOR == 0[/code]
line in gmp-aux.h. That breaks as soon as GMP >= 4.0 is used (and GMP 4.0 is already very old). It should read
[code]#if __GNU_MP_VERSION < 3 || (__GNU_MP_VERSION == 3 && __GNU_MP_VERSION_MINOR == 0)[/code]

After reinventing this fix, I noticed that [url]https://github.com/radii/ggnfs/commits/master[/url] contains several cleanup commits, among which is the above fix (for all affected files).

[QUOTE=debrouxl;274246]I got that error myself recently. The "conflicting types for __gmpz_mul_si" error is because of the
[code]#if __GNU_MP_VERSION < 3 || __GNU_MP_VERSION_MINOR == 0[/code]line in gmp-aux.h. That breaks as soon as GMP >= 4.0 is used (and GMP 4.0 is already very old). It should read
[code]#if __GNU_MP_VERSION < 3 || (__GNU_MP_VERSION == 3 && __GNU_MP_VERSION_MINOR == 0)[/code]After reinventing this fix, I noticed that [URL]https://github.com/radii/ggnfs/commits/master[/URL] contains several cleanup commits, among which is the above fix (for all affected files).[/QUOTE]
I made the change in three gmp-aux.h files and two if.h files and make works fine in the lasieve4_64 folder now. However, then the trunk make x86_64 couldn't find the files.

Looking over the console output, I traced the omissions to a link in the trunk/src/lasieve4 folder. I copied the new liblasieveI4*.a files into that folder and trunk make x86_64 now runs through.

Can I "assume" the created files are compiled correctly? Is there a test other than looking for crashes down the road?

BTW, If the gmp-aux.h and if.h changes were committed, as seemingly reported on the github page, shouldn't those changes be in the current sourceforge revision? It obviously updated from yesterday (r 414) to today (r 416), so I must be checking out a current revision, or am I missing something?

Thanks again for all the help.

Now to piece this together into a coherent set of instructions...

[QUOTE=EdH;274245]...I was able to get a clean copy from sourceforge today. It says version 416. Maybe the updating was why I couldn't get it last night...[/QUOTE]
No, SVN update takes a millisecond if even that.

The [URL="http://ggnfs.svn.sourceforge.net/viewvc/ggnfs/"]416 change[/URL] had nothing to do with the siever anyway; it was an old hack that I've been using for over a year for the perl script. My 2c into the community's meandering argument about how many relations are needed. If anything, this change doesn't hurt the perl script. ("...and besides, the pig likes it!")

Also, in msieve trunk the expected E value estimate is slightly improved for deg 5 and for deg4 -np. (by way of fitting some reasonably extensive historical data from real-life runs.) The "expected" E value is printed into msieve.log when -np is started; NB: the upper limit is arbitrary, it can be easily exceeded if you run -np much, much longer. When -np process has already run for a while, one may check the .p file for the best combined score and make a decision if it is already good enough for them (this decision may be based on many, many factors, e.g. how many CPUs will be used for sieving etc) and kill the -np process or leave it run some more. Of course, the default action to let it run until it stops is fine, too.


[SIZE=1]P.S. Cannot understand why your "ln -s athlon64 asm" fails. Check "ls -ld asm"; maybe it already exists and is [I]a file[/I]?![/SIZE]

Darn [strike]the[/strike] my luck! Either my current c121 is particularly stubborn, or I've run into an old msieve polyfind AMD CPU annoyance. Polyfind just won't quit. It's been running for several hours.

Anyway, for the near term, I changed aliqueit.ini and am invoking the time limit via factmsieve.py that Brian added several months ago for this situation. I'll know more in a little while...

Thanks again to everyone for helping me stay with this.