Build Instructions for Ubuntu 14.04 - Page 2

EdH · 2014-12-11, 20:13

A curiosity: I was wondering why you elect to use NO_ZLIB=1 in your msieve compile? The only time I use that option is if I'm going to subsequently compile YAFU with NFS=1 and I actually do that separate. I'm not really sure that's necessary anymore.

Did you still want a copy of factmsieve 0.76? I assumed not, since you have it working, but thought I'd check. It may actually still be available somewhere in the original thread, anyway.

At some point, would you be opposed to me adding this script, or a link to it, (with a reference to you), to my page?

D. B. Staple · 2014-12-12, 01:52

Quote:

I was wondering why you elect to use NO_ZLIB=1 in your msieve compile?

This is probably not necessary. I selected that because I was following as closely as possible to the instructions on your website, when I was trying to isolate the issue.

Quote:

Did you still want a copy of factmsieve 0.76?

No, thanks. I should've mentioned that. As you said, I only wanted it for debugging.

Quote:

At some point, would you be opposed to me adding this script, or a link to it, (with a reference to you), to my page?

Please do! Hopefully it saves someone else some work. You don't need to reference me, but that is also appreciated.

I think the main difficulty with installing Msieve, GGNFS, and factmsieve.py is that there are a lot of different versions floating around for all three of these items, and there is no prominent place where the build (and use) instructions are concisely documented. Last time I used this tool was in 2011, and I had similar issues (although it was yet another out-of-date version of GGNFS that caused the issue). Ideally, the broken GGNFS code would be taken offline, and centralized instructions (like the ones in this thread, or those on your website) would be prominently displayed.

EdH · 2014-12-12, 05:19

I'm remembering the same now, and it's probably documented on this forum, of running into the ggnfs troubles and swapping over to the github version at that point.

I might offer your script up in a couple of forms: your original, and one more slated to cover the first sections of my procedure. It will probably be a few days, but I will get back with you for further review.

Thanks.

jasonp · 2014-12-15, 01:18

NFS=1 was made obsolete years ago; it was present to allow stripping out a dependency on the (GPL) Gnu Scientific Library. Starting around 2007 that dependency was removed.

NO_ZLIB=1 is primarily meant for compiling on windows; Brian Gladman has added Visual Studio builds of zlib, but I don't use Visual Studio. Of course on unix systems everybody has that library (though your version may be shockingly old).

bsquared · 2014-12-15, 02:53

Quote:

Originally Posted by jasonp

NFS=1 was made obsolete years ago; it was present to allow stripping out a dependency on the (GPL) Gnu Scientific Library. Starting around 2007 that dependency was removed.

I believe he's talking about YAFU, where NFS=1 is still necessary to enable nfs code.

EdH · 2014-12-15, 05:20

Quote:

Originally Posted by bsquared

I believe he's talking about YAFU, where NFS=1 is still necessary to enable nfs code.

That is correct, as I had stated, "... compile YAFU with NFS=1..." Thank you for letting me know it is still the case.

VBCurtis · 2015-10-14, 07:51

I've gotten the sourceforge 1.52 release to compile, as well as the most-recent SVN thanks to the instructions in this thread. However, I cannot get CUDA=1 to compile. I have CUDA 7.5, as well as 5.5, installed, Ubuntu 14.04. The first error is a failure to find cuda.h, so I found it manually and copied it into the msieve include folder.

I get a long list of compiler errors CUevent and CUresult as unknown types, many of them also mentioning macro CUDA_TRY. I am no programmer, so these mean nothing to me.

I suspected CUDA 7.5 was the issue, but I've read that multiple SDKs are okay to have installed, so I added 5.5 but did not uninstall 7.5. Perhaps the CUDA include path points to 7.5's files, which have changed some types so msieve won't work?

Does anyone have a CUDA-enabled linux64 binary? My card is a 750Ti, purchased from Xyzzy, cc 5.0. I am happy with any result that allows me to run poly select on this card, either compilation suggestions or a binary.

RichD · 2015-10-14, 13:53

I've run into the same problem off and on. Every time there is an update, it seems to break the linkage between CUDA, msieve, mfaktc and/or display driver.

Luckily I saved off a working copy which is attached. I think the build includes msieve 975 and CUDA 5.5 or 6.0.

Let me know if it helps. I've been so hesitant to perform any type of software updates lately.

henryzz · 2015-10-14, 16:44

CUDA 5.5 is the last version of cuda that msieve will work for due to an unsupported library.
@VBCurtis you need to set a environment variable or two to point to where the cuda stuff is.

VBCurtis · 2015-10-14, 17:20

Quote:

Originally Posted by henryzz

CUDA 5.5 is the last version of cuda that msieve will work for due to an unsupported library.
@VBCurtis you need to set a environment variable or two to point to where the cuda stuff is.

Does this mean I should uninstall 7.5, then install 5.5? Or will having both on the system work acceptably if I can point msieve to the right CUDA? This box only exists for NFS and ECM work (Core2quad8300), so even a fresh ubuntu install to start over on drivers is no big deal.

henryzz · 2015-10-14, 20:29

Quote:

Originally Posted by VBCurtis

Does this mean I should uninstall 7.5, then install 5.5? Or will having both on the system work acceptably if I can point msieve to the right CUDA? This box only exists for NFS and ECM work (Core2quad8300), so even a fresh ubuntu install to start over on drivers is no big deal.

If you have 5.5 installed then you should have the correct dlls(or Linux equivalent) as long as you have set up the environment variable to point to it.
I am not sure what the situation is if you have two versions installed on Linux.
Have you been able to find a binary? It should complain if you run it asking for dlls.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Broadwell new instructions	tha	Hardware	6	2014-07-18 00:08
Useless SSE instructions	__HRB__	Programming	41	2012-07-07 17:43
Project instructions	MooooMoo	Twin Prime Search	9	2006-06-06 13:30
Instructions to manual LLR?	OmbooHankvald	PSearch	3	2005-08-05 20:28
Instructions please?	jasong	Sierpinski/Riesel Base 5	10	2005-03-14 04:03

2014-12-11, 20:13	#12
EdH "Ed Hall" Dec 2009 Adirondack Mtns 53·89 Posts	A curiosity: I was wondering why you elect to use NO_ZLIB=1 in your msieve compile? The only time I use that option is if I'm going to subsequently compile YAFU with NFS=1 and I actually do that separate. I'm not really sure that's necessary anymore. Did you still want a copy of factmsieve 0.76? I assumed not, since you have it working, but thought I'd check. It may actually still be available somewhere in the original thread, anyway. At some point, would you be opposed to me adding this script, or a link to it, (with a reference to you), to my page?

2014-12-12, 05:19	#14
EdH "Ed Hall" Dec 2009 Adirondack Mtns 126D₁₆ Posts	I'm remembering the same now, and it's probably documented on this forum, of running into the ggnfs troubles and swapping over to the github version at that point. I might offer your script up in a couple of forms: your original, and one more slated to cover the first sections of my procedure. It will probably be a few days, but I will get back with you for further review. Thanks.

2014-12-15, 01:18	#15
jasonp Tribal Bullet Oct 2004 5×709 Posts	NFS=1 was made obsolete years ago; it was present to allow stripping out a dependency on the (GPL) Gnu Scientific Library. Starting around 2007 that dependency was removed. NO_ZLIB=1 is primarily meant for compiling on windows; Brian Gladman has added Visual Studio builds of zlib, but I don't use Visual Studio. Of course on unix systems everybody has that library (though your version may be shockingly old).

2015-10-14, 07:51	#18
VBCurtis "Curtis" Feb 2005 Riverside, CA 7×769 Posts	I've gotten the sourceforge 1.52 release to compile, as well as the most-recent SVN thanks to the instructions in this thread. However, I cannot get CUDA=1 to compile. I have CUDA 7.5, as well as 5.5, installed, Ubuntu 14.04. The first error is a failure to find cuda.h, so I found it manually and copied it into the msieve include folder. I get a long list of compiler errors CUevent and CUresult as unknown types, many of them also mentioning macro CUDA_TRY. I am no programmer, so these mean nothing to me. I suspected CUDA 7.5 was the issue, but I've read that multiple SDKs are okay to have installed, so I added 5.5 but did not uninstall 7.5. Perhaps the CUDA include path points to 7.5's files, which have changed some types so msieve won't work? Does anyone have a CUDA-enabled linux64 binary? My card is a 750Ti, purchased from Xyzzy, cc 5.0. I am happy with any result that allows me to run poly select on this card, either compilation suggestions or a binary.

2015-10-14, 16:44	#20
henryzz Just call me Henry "David" Sep 2007 Liverpool (GMT/BST) 2³·7·107 Posts	CUDA 5.5 is the last version of cuda that msieve will work for due to an unsupported library. @VBCurtis you need to set a environment variable or two to point to where the cuda stuff is.