CentOS 6 and prime95 29.2

[Prime95]

Prime95 version 29.1 is built with the rather ancient CentOS 5 so that downloaders of mprime do not run into an issue where mprime requires a newer C runtime library than is present on their system.

Version 29.2 will not compile because I'm including SQLite which uses some pthread options that apparently did not exist 10 years ago.

The question: Do you think switching to building 29.2 on CentOS 6.9 will cause problems for many users?

[chalsall]

Originally Posted by Prime95

The question: Do you think switching to building 29.2 on CentOS 6.9 will cause problems for many users?

Most likely, no. I have never had a problem running mprime under any modern environment.

But, why don't you simply spin up a CentOS 7 instance, and compile a fully staticly linked executable?

[Prime95]

Chris, you're the one that recommended building on a CentOS 5 system. That has worked rather well.

Mprime cannot be linked statically. Apparently there are some C runtime functions that preclude that. I don't remember which one mprime is tripping over. The last time I tried was several years ago.

[chalsall]

Originally Posted by Prime95

Mprime cannot be linked statically. Apparently there are some C runtime functions that preclude that. I don't remember which one mprime is tripping over. The last time I tried was several years ago.

All programs can be staticly linked. The executable will be larger than with dynamic libraries, but they will run everywhere where the code is compatable with the CPU.

We've got some very smart programmers around these here parts. Let's figure this out.

[nordi]

Originally Posted by Prime95

The question: Do you think switching to building 29.2 on CentOS 6.9 will cause problems for many users?

I don't think it will, since most systems will be running either CentOS 6 or something newer. The few systems still on CentOS 5 can just keep running 29.1 for the rest of their lives.

Originally Posted by chalsall

All programs can be staticly linked. The executable will be larger than with dynamic libraries, but they will run everywhere where the code is compatable with the CPU.

It's not quite so simple. Kernel APIs also change, even for such common syscalls as open(). If I recall correctly it is the recently introduced (=10 years ago) O_CLOEXEC flag that had a different meaning for the ancient RHEL 4 kernel, which interpreted it as "only open the file if it is already cached". This means a statically compiled binary using new libraries will randomly fail to open files on RHEL 4. We learned this the hard way.

[chalsall]

Originally Posted by nordi

It's not quite so simple. Kernel APIs also change, even for such common syscalls as open().

Please forgive me for this, but bullshit. And the horse you rode in on.

[Prime95]

This URL, http://stackoverflow.com/questions/1...ostbyname?lq=1 , describes my problem along with possible solutions.

[chalsall]

Originally Posted by chalsall

Please forgive me for this, but bullshit. And the horse you rode in on.

My sincere apologies for that very inappropriate response. I was having a very bad day....

[chalsall]

Originally Posted by Prime95

This URL, http://stackoverflow.com/questions/1...ostbyname?lq=1 , describes my problem along with possible solutions.

Please note that the gethostbyname() function is obsolete.

I will spend some time over the long weekend trying to tweak the mprime source code such that it can compile a static executable.

[chalsall]

Hey George.

So, I began the compile experiments, but immediately encountered some difficulties.

Is there a build guide anywhere?

[chalsall@burrow gimps]$ cd test1/
[chalsall@burrow test1]$ ls
comm95b.c  comm95c.c  commona.c  commonb.c  commonc.c  common.h  gwnum     linux    macosx    md5.c  p95v2810.source.zip  primenet.c  qd      winnt
comm95b.h  comm95c.h  commona.h  commonb.h  commonc.h  ecm.c     gwtest.c  linux64  macosx64  os2    prime95              primenet.h  tput.c
[chalsall@burrow test1]$ cd linux
[chalsall@burrow linux]$ ls
factor32.o  makebsd  makefile  makehaikugcc2  makehaikugcc4  menu.c  os_routines.c  prime.c  prime.h
[chalsall@burrow linux]$ make
[ ! -e ../security.h ] && touch ../security.h || true
[ ! -e ../security.c ] && touch ../security.c || true
[ ! -e ../secure5.c ] && touch ../secure5.c || true
gcc -I.. -I../gwnum -O2 -march=i486 -malign-double -c prime.c
prime.c:1:0: error: CPU you selected does not support x86-64 instruction set
 /* Copyright 1995-2016 Mersenne Research, Inc. */
 
prime.c:1:0: error: CPU you selected does not support x86-64 instruction set
makefile:49: recipe for target 'prime.o' failed
make: *** [prime.o] Error 1
[chalsall@burrow linux]$ cd ..
[chalsall@burrow test1]$ cd linux64
[chalsall@burrow linux64]$ make
[ ! -e ../security.h ] && touch ../security.h || true
[ ! -e ../security.c ] && touch ../security.c || true
[ ! -e ../secure5.c ] && touch ../secure5.c || true
gcc -I.. -I../gwnum -I/usr/local/include -DX86_64 -O2  -c prime.c
In file included from prime.c:109:0:
../primenet.c:49:23: fatal error: curl/curl.h: No such file or directory
 #include <curl/curl.h>
                       ^
compilation terminated.
makefile:42: recipe for target 'prime.o' failed
make: *** [prime.o] Error 1

[science_man_88]

Originally Posted by chalsall

Please note that the gethostbyname() function is obsolete.

I will spend some time over the long weekend trying to tweak the mprime source code such that it can compile a static executable.

http://stackoverflow.com/questions/6...-gethostbyname suggest alternatives.