OK, I give up!!
[code]
-> gnfs-lasieve4I13e -k -o spairs.out.T0 -v -n0 -a test.job.T0
-> gnfs-lasieve4I13e -k -o spairs.out.T1 -v -n1 -a test.job.T1
/home/duser/Math/ggnfs/trunk/bin/gnfs-lasieve4I13e: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory
/home/duser/Math/ggnfs/trunk/bin/gnfs-lasieve4I13e: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory
-> Return value 127. Updating job file and terminating...
Terminating...
WARNING: gnfs failed to find a factor. This really shouldn't happen.
...
[/code]libgmp.so.10 is in /usr/local/lib

And to think this was mostly working until I tried to "do-it-right" to create the 11, 15 and 16 lasieve4I's...

Add 'LD_LIBRARY_PATH=/usr/local/lib' to the command line starting the script that's starting gnfs-lasieve4I13e. Or copy libgmp.so.10 to /usr/lib.

[QUOTE=fivemack;274355]Add 'LD_LIBRARY_PATH=/usr/local/lib' to the command line starting the script that's starting gnfs-lasieve4I13e. Or copy libgmp.so.10 to /usr/lib.[/QUOTE]
Actually, libgmp.so.10 in the /usr/local/lib folder, turned out to be a symbolic link to /usr/local/libgmp.so.10.0.2. Copying the link didn't work, so I made a new link in the /usr/lib folder and still no-go.

I deleted that link and copied libgmp.so.10.0.2 into the /usr/lib folder and made a new link. Same result...

Thanks for trying...

Just to recap:

I originally ran the make x86_64 in ggnfs/trunk and accepted the errors. Then I copied frmky's set of binaries into the ggnfs/bin directory (overwriting those that were created) and all ran fine until lasieve4I11 was called, which was never created (the error) and frmky's set didn't include it.

At that point I started the current adventure, thinking there should be a manner to make the ggnfs/trunk make x86_64 version work. Apparently, it's not that simple.

I am probably going to go back to the beginning and see if that version still works...

EdH, run
[code]ldd gnfs-lasieve4I13e[/code]
and see what version of libgmp it is trying to use.

For example, mine has:
[code] linux-vdso.so.1 => (0x00007fffa0bff000)
[b]libgmp.so.3[/b] => /usr/local/lib64/libgmp.so.3 (0x0000003f17c00000)
libm.so.6 => /lib64/libm.so.6 (0x00000031e6e00000)
libc.so.6 => /lib64/libc.so.6 (0x00000031e6a00000)
/lib64/ld-linux-x86-64.so.2 (0x00000031e6600000)[/code]

[QUOTE=jrk;274369]EdH, run
[code]ldd gnfs-lasieve4I13e[/code]and see what version of libgmp it is trying to use.

For example, mine has:
[code] linux-vdso.so.1 => (0x00007fffa0bff000)
[B]libgmp.so.3[/B] => /usr/local/lib64/libgmp.so.3 (0x0000003f17c00000)
libm.so.6 => /lib64/libm.so.6 (0x00000031e6e00000)
libc.so.6 => /lib64/libc.so.6 (0x00000031e6a00000)
/lib64/ld-linux-x86-64.so.2 (0x00000031e6600000)[/code][/QUOTE]
[code]
linux-vdso.so.1 => (0x00007fff327ff000)
libgmp.so.10 => not found
libm.so.6 => /lib64/libm.so.6 (0x000000303f200000)
libc.so.6 => /lib64/libc.so.6 (0x000000303e200000)
/lib64/ld-linux-x86-64.so.2 (0x000000303de00000)
[/code]Looking at the above, I made a symbolic link in the /lib64 folder and now receive the following:
[code]
linux-vdso.so.1 => (0x00007ffffe8b1000)
libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f7fb24ab000)
libm.so.6 => /lib64/libm.so.6 (0x000000303f200000)
libc.so.6 => /lib64/libc.so.6 (0x000000303e200000)
/lib64/ld-linux-x86-64.so.2 (0x000000303de00000)
[/code]However, I now get this:
[code]
appending spairs.out.T0 to spairs.out
appending spairs.out.T1 to spairs.out
-> Return value -11. Updating job file and terminating...
appending spairs.out to spairs.add
Terminating...
[/code]Could this -11 be due to using different trials on the same files in the ggnfs_###### directory formed by aliqueit and not due to ggnfs errors? I can't put any more time in to experimenting right now, though. I have to run for a bit.

One other thing that might be causing some trouble: I installed from stand-a-lone gmp-ecm on top of the already existing repository version of gmp-ecm trying to see if I could find gmp-ecm-devel. The stand-a-lone was 5.0.2, while the Fedora repository one is 6.3-1.fc15 (x86_64). I don't know if there may be some conflict, or how to uninstall 5.0.2. It doesn't show up in the GUI and I'm not sure if yum would work...

Anyway, thanks for all the help in trying to get this running.

As a side note, the system is running fine with the original ggnfs installation and overwrite at the moment. The frmky binaries are static though, so I can't check for dependencies for those.

[QUOTE=EdH;274378]...The frmky binaries are static though, so I can't check for dependencies for those.[/QUOTE]
Some of the bugs in the siever are only observed in dynamically linked binaries. Static linking of libgmp.a is recommended.

[QUOTE=EdH;274378]One other thing that might be causing some trouble: I installed from stand-a-lone gmp-ecm on top of the already existing repository version of gmp-ecm trying to see if I could find gmp-ecm-devel. The stand-a-lone was 5.0.2, while the Fedora repository one is 6.3-1.fc15 (x86_64). I don't know if there may be some conflict, or how to uninstall 5.0.2. It doesn't show up in the GUI and I'm not sure if yum would work...[/QUOTE]

I think I see a misconception here. GMP is a library used by other packages to do large integer arithmetic. GMP-ECM is a program which uses the GMP library and tries to factor numbers using the Elliptic Curve Method.

GMP (the library) is currently at version 5.0.2. Since you say GMP 5.0.2 is installed, you are done with this step.

GMP-ECM (the program) is currently at version 6.3.0. Since you say you have 6.3-1.fc15 (the -1.fc15 is just Fedora package info, not related to GMP-ECM), you are done with this step.

It looks like once you set the library path with:
[QUOTE]I made a symbolic link in the /lib64 folder and now receive the following:[/QUOTE] you now have a working ggnfs. The error you saw was probably due to running aliquiet/ggnfs on different inputs and ggnfs didn't like one of the files it found. Trying again with a "cleaned up" directory should proceed without any problems.

[QUOTE=WraithX;274422]I think I see a misconception here. GMP is a library used by other packages to do large integer arithmetic. GMP-ECM is a program which uses the GMP library and tries to factor numbers using the Elliptic Curve Method.

GMP (the library) is currently at version 5.0.2. Since you say GMP 5.0.2 is installed, you are done with this step.

GMP-ECM (the program) is currently at version 6.3.0. Since you say you have 6.3-1.fc15 (the -1.fc15 is just Fedora package info, not related to GMP-ECM), you are done with this step.

It looks like once you set the library path with:
you now have a working ggnfs. The error you saw was probably due to running aliquiet/ggnfs on different inputs and ggnfs didn't like one of the files it found. Trying again with a "cleaned up" directory should proceed without any problems.[/QUOTE]
Thanks WraithX,

That does clear things up a bit. However, I have two different ggnfs directories that I rename and swap back and forth: one is the original (working with frmky's binaries) and the other is the current "troublemaker." I rename these back and forth. I also get rid of the gnfs_### directory that aliqueit creates. I just now created a second aliqueit directory so they would be totally isolated in regards to intermediate aliqueit generated files that reside in the aliqueit folder.

Unfortunately, I still get the -11 error. But, this time it might be due to the polyfind routine. Since it seems to go on forever, I have put a hard wall clock limit on it. Currently I have it set to 20 minutes for testing. Maybe that is not enough time to find an adequate poly for this c121. I don't know what -11 signifies.

if it fails the current test, I'm going to step back to a smaller composite to test with and a longer wall time. But that will have to wait until tomorrow.

Thanks for the clarification.

Edit: No success. I tried a c115 and a c96. Without knowing what -11 means, I'm pretty much stuck...

I am trying to compile the experimental siever with Visual Studio 2010 at the moment. I now get several errors.

[QUOTE]
Error 2 error C1083: Cannot open include file: 'alloca.h': No such file or directory D:\factorsoft\ggnfs\build.vc10\lasieve.exp\if.w lasieve4I11e
Error 10 error C1083: Cannot open source file: '..\..\asprintf.c': No such file or directory D:\factorsoft\ggnfs\build.vc10\lasieve.exp\lasieve4I11e\c1 lasieve4I11e
11 IntelliSense: PCH warning: line directives cannot be used in a PCH. An intellisense PCH file was not generated. d:\factorsoft\ggnfs\src\experimental\lasieve4_64\if.h 2 2
[/QUOTE]

Any ideas what I should do?

I think alloca() is defined in malloc.h on windows.

This is because I did not commit the extra files needed to build the experimental siever with Visual Studio. I have now done this but I cannot find my Visual Studio *.vcxproj or *.sln files to build it so its not tested.