Packaging Mlucas for Debian
 

Alex Vong (a.k.a. alexvong1995 on this forum) approached me about packaging Mlucas for Debian, and I agreed to let (and help) him do so. There are no issues with the source code (which has always been GPLed), but [url=http://hogranch.com/mayer/README.html]my how-to page[/url] has always just assigned copyright to me, and he said he also needs that to be GPLed.

With regard to releasing my README file under GPL, one obvious question is: "Does such an html-encoded document qualify as 'software' under the terms of the GPL?". By way of a shortcut to a possible answer, I scrolled to the bottom of Gnu's own GPL FAQ ([url]https://www.gnu.org/licenses/gpl-faq.html[/url]) and saw this copyright notice there:
[i]
This page is licensed under a [url=http://creativecommons.org/licenses/by-nd/3.0/us/]Creative Commons Attribution-NoDerivs 3.0 United States License[/url].
[/i]
And, perusing [url]https://www.gnu.org/licenses/license-list.html[/url] the above license is described thusly:
[i]
This is the license used throughout the GNU and FSF web sites. This license provides much the same permissions as our verbatim copying license, but it's much more detailed. We particularly recommend it for audio and/or video works of opinion. Please [url=https://www.gnu.org/licenses/license-list.html#which-cc]be specific about which Creative Commons license is being used[/url].
[/i]
But note the "works of opinion" bit - I don't see a software-how-to guide as falling into that category.

Basically, I am happy to attach a GPL note to my README file(s), but don't want a 20-line chunk of text (as is at the top of my GPLed source code files) appearing in an html-displayed webpage - would a simple one-line statement analogous to the above CC 3.0 license notice, and embedding a link to Gnu's GPL site, suffice? (I could still paste the full-length GPL boilerplate as a comment at top of the html source.)

Advice from the GPL wonks appreciated...

[url]http://en.wikipedia.org/wiki/GNU_Free_Documentation_License[/url]

Note that the contents of this forum (all our collective posts!) are available under the terms of this license.

Thanks -- [url=http://hogranch.com/mayer/README.html]done[/url].

Next issue: Alex reports having more-or-less blanket compile-error issues in his attempts to build the code in 32-bit mode (which I routinely do successfully on my old Core-duo based macbook using gcc) on a 64-bit debian system.

I tried same on on debian (v6) haswell quad just now and confirmed - using 'gcc -c -m32 -Os *.c', all sources except for the tiny types.c file fail with
[i]
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory[/i]

===============

[b]Edit:[/b] Web-search gives (among other things) [url=http://stackoverflow.com/questions/7412548/error-gnu-stubs-32-h-no-such-file-or-directory-while-compiling-nachos-source]this stackoverflow thread[/url] which fingers a missing 32 bit libc dev package:
[i]
On Ubuntu it's called libc6-dev-i386 - do sudo apt-get install libc6-dev-i386. See below for extra instructions for Ubuntu 12.04.
[/i]
Alex, that works for me - please give it a try. (Under debian you'll want to omit the 'sudo' and install as root instead.)

[QUOTE=ewmayer;403110]Next issue: Alex reports having more-or-less blanket compile-error issues in his attempts to build the code in 32-bit mode (which I routinely do successfully on my old Core-duo based macbook using gcc) on a 64-bit debian system.

I tried same on on debian (v6) haswell quad just now and confirmed - using 'gcc -c -m32 -Os *.c', all sources except for the tiny types.c file fail with
[I]
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory[/I][/QUOTE]
I would like to know if you are using the original 14.1 source code or the latest version with modifications you have sent to me? If it is the original 14.1 source code, then I get
[CODE]Mlucas.o: In function `Mlucas_init':
Mlucas.c:(.text+0x63): undefined reference to `test_fft_radixtables'
Mlucas.c:(.text+0x77): undefined reference to `get_fft_radices'
Mlucas.c:(.text+0xcc): undefined reference to `get_fft_radices'
Mlucas.c:(.text+0x10f): undefined reference to `given_N_get_maxP'
Mlucas.o: In function `ernstMain':
Mlucas.c:(.text+0x3b51): undefined reference to `get_default_fft_length'
Mlucas.c:(.text+0x3b78): undefined reference to `given_N_get_maxP'
Mlucas.c:(.text+0x41c3): undefined reference to `get_default_fft_length'
Mlucas.c:(.text+0x4231): undefined reference to `get_fft_radices'
Mlucas.c:(.text+0x4394): undefined reference to `get_fft_radices'
Mlucas.c:(.text+0x43ac): undefined reference to `get_fft_radices'
Mlucas.c:(.text+0x4579): undefined reference to `get_default_fft_length'
Mlucas.c:(.text+0x4590): undefined reference to `given_N_get_maxP'
Mlucas.c:(.text+0x45b0): undefined reference to `get_nextlarger_fft_length'
Mlucas.c:(.text+0x5288): undefined reference to `get_nextlarger_fft_length'
Mlucas.o: In function `main':
Mlucas.c:(.text.startup+0x586b): undefined reference to `get_fft_radices'
Mlucas.c:(.text.startup+0x5fb7): undefined reference to `get_fft_radices'
Mlucas.c:(.text.startup+0x6222): undefined reference to `get_fft_radices'
Mlucas.c:(.text.startup+0x6a8a): undefined reference to `given_N_get_maxP'
Mlucas.c:(.text.startup+0x6b31): undefined reference to `get_default_fft_length'
Mlucas.c:(.text.startup+0x71ed): undefined reference to `get_fft_radices'
Mlucas.c:(.text.startup+0x76cf): undefined reference to `get_fft_radices'
gcd_lehmer.o: In function `gcd_init':
gcd_lehmer.c:(.text+0xe): undefined reference to `test_fft_radixtables'
gcd_lehmer.c:(.text+0x62): undefined reference to `get_fft_radices'
gcd_lehmer.c:(.text+0xaf): undefined reference to `get_fft_radices'
gcd_lehmer.c:(.text+0xec): undefined reference to `given_N_get_maxP'
mers_mod_square.o: In function `mers_mod_square':
mers_mod_square.c:(.text+0x42c3): undefined reference to `radix44_dif_pass1'
mers_mod_square.c:(.text+0x4341): undefined reference to `radix176_dif_pass1'
mers_mod_square.c:(.text+0x55bf): undefined reference to `radix44_ditN_cy_dif1'
mers_mod_square.c:(.text+0x58a3): undefined reference to `radix176_ditN_cy_dif1'
mers_mod_square.c:(.text+0x6324): undefined reference to `radix44_dit_pass1'
mers_mod_square.c:(.text+0x63a2): undefined reference to `radix176_dit_pass1'
pairFFT_mul.o: In function `pairFFT_mul':
pairFFT_mul.c:(.text+0x531): undefined reference to `get_fft_radices'
collect2: error: ld returned 1 exit status
[/CODE] after compile and linking with `gcc -c -m32 -Os *.c' and `gcc -o mlucas -m32 *.o -lm'
Since we are doing single-threaded build, we don't need to link librt and libpthread.

These compilation errors are fixed in the modifications you have sent to me although the compiled program doesn't pass the self-test, which I will elaborate more later.

So it seems we have received different errors in single-threaded build. I will also look into multi-threaded build later.

Alex, your post overlapped some edits to my above one which I had queued up but delayed as a result of having to step away from my desk for a while. Based on your note it looks like your 32-bit issue differs from mine. (I am using the unmodified 14.1 source for these packaging-related builds, unless specifically noted.)

Your linker errors suggest that you did not compile get_fft_radices.c successfully - do you see a get_fft_radices.o file? If not, try compiling just that source and let me know what error(s) you get.

Alex, I only did a quick 1-file compile test to check the 32-bit libc install at first, then fired up a full build. Indeed get_fft_radices.c gives a compile error - it's the duplicate-case-value bug you found in your unthreaded non-SSE2 64-bit build. Use the patched version of that file - looks like you'll also need the scalar-mode build patches in the radix44*c and radix176*c files I sent. You might as well use the scalar-build patched mers_mod_square.c file as well.

Oh - not sure what link args you're using but I needed to insert '-m32' between the 'gcc' and '-o' in my 32-bit link step, since this is a 64-bit system.

[QUOTE=ewmayer;403123]Alex, I only did a quick 1-file compile test to check the 32-bit libc install at first, then fired up a full build. Indeed get_fft_radices.c gives a compile error - it's the duplicate-case-value bug you found in your unthreaded non-SSE2 64-bit build. Use the patched version of that file - looks like you'll also need the scalar-mode build patches in the radix44*c and radix176*c files I sent. You might as well use the scalar-build patched mers_mod_square.c file as well.

Oh - not sure what link args you're using but I needed to insert '-m32' between the 'gcc' and '-o' in my 32-bit link step, since this is a 64-bit system.[/QUOTE]
Awww. It seems I have confused you. The duplicate-case-value bug and the other 3 are actually found when I was doing unthreaded non-SSE2 32-bit build, not a 64-bit one. I found them because the compiler complained about them. I don't try to build unthreaded non-SSE2 64-bit build because all 64-bit processors should at least have SSE2 (It seems Wikipedia confirms that?). So I am now trying to do unthreaded non-SSE2 32-bit build and multithreaded SSE2/AVX/AVX2 64-bit build. Actually, I want multithread build in both cases but 4 source files failed to build in the 32-bit case. Hmmm I should look into it later.

Regarding libc6-dev-i386. Yes, it seems I have installed it previously. Maybe I was trying to build something that I can't remember right now. Good it solves your problem.
And yes we need `-m32' to build 32-bit binary in every step or the compiler would get upset.