How to Compile mprime Under Linux

[Blaise Pascal]

I know that an executable exists in Linux for mprime/sprime, but for the heck of it, I'd like to compile the source code. How do I do it? I have gcc installed.

Also, I see that mprime is dynamically linked and that sprime is statically linked. I'm not much of a programmer; what do these mean?


Thanks,
BP


0009

[Mystwalker]

Correct me if I'm wrong, but AFAIK, the security module of the client is not available as open source. Thus it's not possible to compile it for yourself.

Concerning the linking, (roughly speaking) static linking means that the linker puts every library part that is being called from the application into the output file. Thus, everything the application needs is within the executable.
Dynamic linking still only references to the libraries, so they can be shared, and replacing them could be a benefit (or a curse, of course) for every dynamically linked program using such libraries. Plus, dynamically linked executables are a lot smaller.
But you have to take care that the needed libraries are at an appropriate position.

[geoff]

You can compile mprime yourself, it won't be able to connect to the primenet server, but everything else will still work. However it is not a 100% automatic process, you need to manually set the alignment of certain functions, there are instructions in the makefile. If you set them wrong it will appear to compile fine but will segfault when you try to do anything useful. Apart from that, it is just a matter of typing 'make'.

[Peter Nelson]

Originally Posted by geoff

You can compile mprime yourself, it won't be able to connect to the primenet server, but everything else will still work. However it is not a 100% automatic process, you need to manually set the alignment of certain functions, there are instructions in the makefile. If you set them wrong it will appear to compile fine but will segfault when you try to do anything useful. Apart from that, it is just a matter of typing 'make'.

I agree with Geoff that it should be entirely possible to compile the source code to run on your linux platform and because of the missing security bits (to avoid false submissions to primenet) you can't talk to primenet using the self-build version. However you can run tests and might choose to submit results manually? Or maybe use it to test primality on an unrelated project?

As I too wanted to compile rather than run the binary, I soon discovered things are not quite so simple.

George wrote some of the code in assembly and the object code is in a more microsoft form than conventional linux object code. (read the docs/sources for more info)

In order to link all the bits together you need your binutils to understand both formats. Most distros do not supply a ready made build of binutils for cross platforms. eg my Suse 9.1 had this problem. So I got the source code to binutils and had to rebuild that specifying additional targets I wanted supported.

I think it likely you will at least need to rebuild binutils in order to get George's stuff compiled.

Being honest I'm still trying to complete this compilation (have had other priorities) but still keen to get it working. So maybe we can post stages of success or not.

P.S. I recognise that squirrel and his "NUTS"

[geoff]

I was able to recompile mprime 23.5 with just the standard tools in Debian I think. (I might have installed something extra and forgot about it though).

[T.Rex]

Hi Peter,

Originally Posted by Peter Nelson

As I too wanted to compile rather than run the binary, I soon discovered things are not quite so simple.
George wrote some of the code in assembly and the object code is in a more microsoft form than conventional linux object code. (read the docs/sources for more info)
In order to link all the bits together you need your binutils to understand both formats. Most distros do not supply a ready made build of binutils for cross platforms. eg my Suse 9.1 had this problem. So I got the source code to binutils and had to rebuild that specifying additional targets I wanted supported.

I also would be able to recompile mprime.
Since I must educate myself about Linux tools enabling to analyze performances of the system or of applications (like OProfile) and about all the process of compiling/linking on Linux, I've tried to use mprime for experimenting.
But it appears that mprime has been stripped. That means that symbols have been removed from the executable file: "nm mprime" says: no symbol. That means I cannot use OProfile.
I've tried to recompile mprime and found the problem you describe:
objcopy -Oelf32-i386 -Icoff-i386 ../prime95/mult.obj mult.o
objcopy: ../prime95/mult.obj: Invalid bfd target
I don't know yet how to rebuild binutils. So I would appreciate to get help.

My final goal with mprime is to see if I could find some improvements for it on Linux. At least, being able to recompile mprime with icc and with appropriate options (says my PC has a Pentium 4) should speed up it, I think.

I would be very pleased to share information about "how to compile mprime on Linux" with other people using Linux.

Tony

[geoff]

Originally Posted by T.Rex

I've tried to recompile mprime and found the problem you describe:
objcopy -Oelf32-i386 -Icoff-i386 ../prime95/mult.obj mult.o
objcopy: ../prime95/mult.obj: Invalid bfd target

The elf32-i386 versions of these files (mult.o etc) are included in the source, there is no need to rebuild them if you don't have the full binutils installed. Maybe the date stamps are wrong, if so just touch each object file before starting make.

Originally Posted by Peter Nelson

P.S. I recognise that squirrel and his "NUTS"

I don't know where that image came from, I think it might be a default that the forum software attaches to users like me who don't supply one of their own :-)

[Prime95]

These are my notes on adding coff support to binutils:

Get binutils source from: ftp://sources.redhat.com/pub/binutils/releases/
./configure
in bfd/config.bfd add i386coff_vec to the targ_selvecs of I[3-7]86-*-linux-gnu* case
make
make install

[T.Rex]

Thanks for your help !

I've tried the 2 approaches:

- touch *.o (which were older than .obj files) :
objcopy now works, but compilation fails when linking.

- download binutils, add the change and recompile it:
I've been able to build a new version of objcopy.
This new objcopy now correctly handles the translation between
coff and elf32 formats.
Everything compiles/links well, but (same with icc or gcc):
./mprime crashes later, at: "Starting primality test of"
gdb ./mprime core.5730
(gdb) where
#0 0x08181074 in xfft6144_1 ()
#1 0x08181516 in xfft6144_2 ()
#2 0x00000000 in ?? ()
I've looked at the settings in the makefile, but found nothing to change.

Seems not easy ...

Any suggestions ?
Thanks, Tony

[Prime95]

Make sure the mult.o data segment is on a 16-byte boundary!

[geoff]

Originally Posted by T.Rex

Everything compiles/links well, but (same with icc or gcc):
./mprime crashes later, at: "Starting primality test of"

You need to set the alignment of the modules mult.o and factor64.o by setting the DUMMY3 and DUMMY4 variables in the makefile. To make things a little easier change the linker flags from LFLAGS = -Wl,-M to LFLAGS = -Wl,-Map=mapfile.txt which will put all the linking info into mapfile.txt instead of sending it to the console. Grep for mult.o in mapfile.txt, if the address is not properly aligned then work out which dummy??.o module needs to be linked to add the right amount of padding. Once it is properly aligned then do the same for factor64.o. It is just trial and error.

BTW typing 'touch *.o' then 'make sprime' links fine for me, so there might be something different with your setup. I am using gcc 3.3.5 and binutils 2.15.