Problems building ggnfs

xilman · 2009-09-27, 20:23

I couldn't find a (recent) thread discussing the material below. If there is somewhere more appropriate, perhaps a moderator would move this stuff there.

Anyway, up until now I've never really tried to use ggnfs for sieving (or anything else for that matter) though I dabbled with it in the past. I thought it time to see what everyone else is excited about. Then I hit problems.

First, the recommended distribution kit still seems to be that on SourceForge and it is over three years old. I know work has been done on ggnfs in that time because I've seen the chatter on the forum.

Is ggnfs-0.77.1-20060513 really the current version? Seems rather doubtful to me.

That version doesn't build on my MacOS Snow Leopard system but until I'm sure there isn't something rather more current there doesn't seem to be much point in posting detailed error messages.

Thanks for any help which may be forthcoming.

Paul

fivemack · 2009-09-27, 20:49

Nobody's made a tarball of the ggnfs code for ages; you want to check out the subversion trunk with

Code:

 svn co https://ggnfs.svn.sourceforge.net/svnroot/ggnfs ggnfs

and I'll be interested to know about build problems on snow leopard because I'm getting a macpro on my desk at work the week after next.

xilman · 2009-09-27, 21:16

Quote:

Originally Posted by fivemack

Nobody's made a tarball of the ggnfs code for ages; you want to check out the subversion trunk with

Code:

 svn co https://ggnfs.svn.sourceforge.net/svnroot/ggnfs ggnfs

and I'll be interested to know about build problems on snow leopard because I'm getting a macpro on my desk at work the week after next.

Okey-doke. I'll try that tomorrow. I'd already found the SVN trunk but hadn't taken it any further before asking for guidance.

MacOS is seriously weird in places. Things don't always work the way they should on a Unix box (and a Mac is fundamentally a Unix box) and all sorts of things are missing. I can see that I'm going to have to install svn, for instance. (Yes, I know SourceForge will build me a tarball if asked nicely, but that's no good way to get software.)

Paul

Wacky · 2009-09-27, 21:38

Quote:

Originally Posted by xilman

MacOS is seriously weird in places. Things don't always work the way they should on a Unix box (and a Mac is fundamentally a Unix box) and all sorts of things are missing.

Quote:

Originally Posted by xilman

I can see that I'm going to have to install svn

Are you sure? Xcode supports svn and I have it on my Snow Leopard system.
I suspect that it is part of the "BSD tools" that you should have installed in order to do any development.

The biggest "gotcha" is that the Apple version of gcc has all kinds of problems building GMP. I haven't checked on the "fink" distribution to see if a good 64-bit GMP library is available.

xilman · 2009-09-28, 05:59

Quote:

Originally Posted by Wacky

Are you sure? Xcode supports svn and I have it on my Snow Leopard system.
I suspect that it is part of the "BSD tools" that you should have installed in order to do any development.

The biggest "gotcha" is that the Apple version of gcc has all kinds of problems building GMP. I haven't checked on the "fink" distribution to see if a good 64-bit GMP library is available.

It appears that I do have svn.

Paul

Jeff Gilchrist · 2009-09-29, 16:58

Quote:

Originally Posted by fivemack

Nobody's made a tarball of the ggnfs code for ages; you want to check out the subversion trunk with

The easiest way to get the latest tarball now is just asking sourceforge to make one out of trunk if you don't have SVN installed:
http://ggnfs.svn.sourceforge.net/vie...ar.gz?view=tar

Jeff.

xilman · 2009-10-07, 17:45

Quote:

Originally Posted by Jeff Gilchrist

The easiest way to get the latest tarball now is just asking sourceforge to make one out of trunk if you don't have SVN installed:
http://ggnfs.svn.sourceforge.net/vie...ar.gz?view=tar

Jeff.

OK, got the tarball, extracted it and typed "make nocona >& make.out". Results as in the attached file.

Would there be any interest in porting this stuff to the regular "./configure; make" approach? There would be quite a learning curve and I'm certainly not going to do it all myself. Even if there is interest, I'll need commit privilege on the repository.

Paul

fivemack · 2009-10-07, 18:24

You really want to build only the lasieve4e and msieve; the GGNFS line siever and post-processing code isn't worth the wombats.

getline isn't in the BSD libc, but reimplementing it kludily is trivial.

Building msieve's easy once you've got gmp. gmp builds OK from source, though the Darwin build of gmp with --prefix=/home/fivemack/sw produces a library which describes its location as /usr/local/lib; I ended up just copying the library there.

But a capable lasieve4e (go to the src/experimental directory, ln -s athlon64 asm, make) seems to be a good deal more trouble. Partly it's BSD Make - you need to have an explicit

asm/*:\n\t$(MAKE) -C asm $*

to get it to iterate down the directory tree, but more fundamentally the OS X assembler has a different attitude to global variables from the Linux one, and just won't accept something like mov constant(%rcx),%rdi where constant refers to a memory location: maybe dotting (%rip) throughout the code might help, but I ended up losing confidence and resuming my normal duties.

2009-09-27, 20:23	#1
xilman Bamboozled! "𒉺𒌌𒇷𒆷𒀭" May 2003 Down not across 2²×5×7²×11 Posts	Problems building ggnfs I couldn't find a (recent) thread discussing the material below. If there is somewhere more appropriate, perhaps a moderator would move this stuff there. Anyway, up until now I've never really tried to use ggnfs for sieving (or anything else for that matter) though I dabbled with it in the past. I thought it time to see what everyone else is excited about. Then I hit problems. First, the recommended distribution kit still seems to be that on SourceForge and it is over three years old. I know work has been done on ggnfs in that time because I've seen the chatter on the forum. Is ggnfs-0.77.1-20060513 really the current version? Seems rather doubtful to me. That version doesn't build on my MacOS Snow Leopard system but until I'm sure there isn't something rather more current there doesn't seem to be much point in posting detailed error messages. Thanks for any help which may be forthcoming. Paul

2009-09-27, 20:49	#2
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 1917₁₆ Posts	Nobody's made a tarball of the ggnfs code for ages; you want to check out the subversion trunk with Code: svn co https://ggnfs.svn.sourceforge.net/svnroot/ggnfs ggnfs and I'll be interested to know about build problems on snow leopard because I'm getting a macpro on my desk at work the week after next. Last fiddled with by fivemack on 2009-09-27 at 20:49

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Help building GMP for prime95 29.3	Prime95	Linux	16	2017-08-29 18:02
Building sr1sieve for RPi	wombatman	Software	14	2017-03-04 16:21
GGNFS problems on Windows	Jeff Gilchrist	Factoring	19	2011-01-16 22:38
Help building new computer	Prime95	Hardware	30	2009-09-12 05:58
Building gcc 4.4.0	CRGreathouse	Software	1	2009-07-07 22:25

2009-10-07, 18:24	#8
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 3×2,141 Posts	You really want to build only the lasieve4e and msieve; the GGNFS line siever and post-processing code isn't worth the wombats. getline isn't in the BSD libc, but reimplementing it kludily is trivial. Building msieve's easy once you've got gmp. gmp builds OK from source, though the Darwin build of gmp with --prefix=/home/fivemack/sw produces a library which describes its location as /usr/local/lib; I ended up just copying the library there. But a capable lasieve4e (go to the src/experimental directory, ln -s athlon64 asm, make) seems to be a good deal more trouble. Partly it's BSD Make - you need to have an explicit asm/:\n\t$(MAKE) -C asm $ to get it to iterate down the directory tree, but more fundamentally the OS X assembler has a different attitude to global variables from the Linux one, and just won't accept something like mov constant(%rcx),%rdi where constant refers to a memory location: maybe dotting (%rip) throughout the code might help, but I ended up losing confidence and resuming my normal duties.