GNU MP 6.1.2 error undefined symbol __gmpn_invert_limb in test t-constants

Tue Aug 29 12:06:30 UTC 2017

[ apologies in advance .. another long long email from Dennis ]

On 8/29/17 3:18 AM, Emmanuel Thomé wrote:
> On Mon, Aug 28, 2017 at 01:28:33PM -0400, Dennis Clarke wrote:
>> ppc64$ ./configure ABI=mode64 --enable-cxx --prefix=/usr/local \
>>> --libdir=/usr/local/lib --build=powerpc970-unknown-linux-gnu
> [...]
>> checking compiler gcc -m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec
>> -mfull-toc -mregnames ... yes
> 
> Hold on, where does that rpath come from ? Is it part of your standard
> set of CFLAGS that come from your environment ?

Is it standard?  Sometimes yes and sometimes no. Depends on the system.
At least for software that can not be built inside a clean room scenario
where you have nothing but a clean system, a kernel, a few toolchain
tools and the gmp sources. The libgmp project is a rare one in which you
really don't need much of anything to get a clean solid build. Nearly
everything else ( like mozilla or apache or anything X-windows based
with GTK/Xlib etc etc ) needs a ton of libs and things for a clean
build. Even XTerm. In those cases the use of the rpath allows me to
ensure and force the whole process to look into libs previously built
into /usr/local/lib.  The situation is more messy on multi-arch systems
which would be the powerpc and sparc systems where ppc64 is also a big
or small endian system depending. However in the power/powerpc world no
one seems to bother with the ability to run little and big endian at the
same time and as a platform it seems to have fallen out of fashion.
Unless an IBM POWER system ( not powerpc ) is available and I am working
on that. Those are real performance monsters and Red Hat Enterprise
Linux is fully supported on them as well as an AIX implementation. As
soon as I lay my hands on one you can bet I will toss gmp on there.

> As Vincent mentioned, I did encounter an issue where gmp was picking the
> wrong lib for the tests. But that was related to idiosyncrasies of the
> antiquated linker used by freebsd. You should not encounter such things
> under gnu/linux, unless you ask it queer things. Which you seem to do
> with that rpath.

It didn't strike me as strange to build gmp with an rpath preset to
exactly where I wanted it. I just built mpfr a moment ago with some env 
vars thus :

CFLAGS=-m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec -mfull-toc 
-mregnames

CXXFLAGS=-m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec 
-mfull-toc -mregnames

LC_ALL=C
LD_LIBRARY_PATH=/usr/local/lib
LD_OPTIONS=-R/usr/local/lib -L/usr/local/lib

No LD_RUN_PATH set there. I am surprised to see LD_LIBRARY_PATH which is
not set anywhere in my setup scripts and I generally avoid it. However I
have been building and re-building and re-building gmp in so many many
different ways on multiple systems I am not surprised that I have
something messy here.  I sort of see gmp as the first stepping stone up
a toolchain.  OKay, actually gnu make with libiconv and gnu gettext is
the real first and then the auto-tools bits and a few, very few, others.

On another topic I was just looking at freebsd and did download the
release 11.1 iso images.  I was going to see if a freebsd based install
was more stable and reliable than the messy debian ppc64 system I have
now. The debian folks have dropped support for ppc64 from their recent
installers however one can certainly run the previous release. That at
least gets me the basic tools. However gcc throws the odd ice ( internal
compiler error ) from time to time and I can trigger that with a few
lines of code.  I have openbsd 6.1 up and running but only on amd64 at
the moment and performance is really terrible thus far. Anyways, here
is an ice :

ppc64$ uname -a
Linux charon 3.16.0-4-powerpc64 #1 SMP Debian 3.16.43-2 (2017-04-30) 
ppc64 GNU/Linux

ppc64$ cat ice_me.c
#define _XOPEN_SOURCE 600

/* what is the limit on the initial estimation stage */
#define MAX_N1 16384
/* at what interval shall data be printed */
#define INTERVAL_N1 256

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <stdint.h>
#include <stddef.h>
#include <errno.h>
#include <math.h>

int main()
{
     uint32_t j, n;
     long double psum = ( long double ) 0.0;
     long double est_pi;

     fprintf ( stdout, "         n       est_pi               delta\n" );
     fprintf ( stdout, "      -------------------------------------\n" );
     /* initial stage of estimation */
     for ( n=1; n<( MAX_N1 + 1 ); n++ ) {

         psum = psum  +      ( (long double) 1.0
                                        /
                             ( (long double) n * (long double) n ) );

         if ( n%INTERVAL_N1 == 0 ) {
             fprintf ( stdout, "\n  %9i    ", n );
             /* fprintf ( stdout, "psum = %18.12Le    ", psum ); */
             est_pi = sqrtl( psum * (long double) 6.0);
             fprintf ( stdout, "%18.12Le    ", est_pi );
             fprintf ( stdout, "%10.4Le",
                  ( (long double) 3.14159265358979323846264 - est_pi ) );
         }
     }
     fprintf ( stdout, "\n" );

     fprintf ( stdout, "\nFinal est_pi IEEE754 long double data :\n" );
     for ( j=0; j<sizeof(long double); j++ ) {
        fprintf( stdout, "%02x ", ((unsigned char *)&est_pi)[j] );
     }
     fprintf ( stdout, "\n" );
     fprintf ( stdout, "NOTE : size of long double on this platform = " );
     fprintf ( stdout, "%i\n", sizeof(long double) );

     return(EXIT_SUCCESS);

}

ppc64$ gcc -m64 -g -ggdb -mcpu=970 -maltivec -mfloat-gprs=double 
-mfull-toc -malign-natural -mhard-float -mdouble-float -mfpu=dp_full 
-mabi=ieeelongdouble -mregnames -c -o ice_me.o ice_me.c
gcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
ppc64$

One can not even try anything too complex or ask for strange compiler
cflags or bingo the compiler faults. So the solution is to build a new
compiler. Which I am trying to work on. A dependency is gmp along with
brethern mpfr, mpc and now isl in there. Not much else is needed to
bootstrap gcc. As for the above I can drop a few options and it will
compile. However an ice should not happen. At all. Why does it? Hard to
say but trivial stuff works fine :

ppc64$ cat ld.c

#include <stdio.h>
#include <stdlib.h>

int main ( int argc, char *argv[] ) {

    int j;
    long double pi = 3.14159265358979323846264338327950288419716939937510L;
    /* pi = 40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8 */
    for ( j=0; j<sizeof(long double); j++ )
        printf("%02x ", ((unsigned char *)&pi)[j] );

    printf("\n" );

    return (EXIT_SUCCESS);

}

ppc64$ gcc -m64 -g -ggdb -mcpu=970 -maltivec -mfloat-gprs=double 
-mfull-toc -malign-natural -mhard-float -mdouble-float -mfpu=dp_full 
-mabi=ieeelongdouble -mregnames -c -o ld.o ld.c
gcc: warning: using IEEE extended precision long double
cc1: warning: using IEEE extended precision long double

ppc64$ gcc -m64 -g -ggdb -mcpu=970 -maltivec -mfloat-gprs=double 
-mfull-toc -malign-natural -mhard-float -mdouble-float -mfpu=dp_full 
-mabi=ieeelongdouble -mregnames -o ld ld.o
gcc: warning: using IEEE extended precision long double

ppc64$ ./ld
40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8
ppc64$

Try that on anything intel/amd and you won't get past 80bits of data.
However on power and sparc and a few others you get the full 128 bits.
Very very slowly. That includes the new sparc M7 monster. *sigh*  This
is solved by gmp which can toss all manner of precision all day long and
do it blistering fast. Stable. Sometimes and on some systems when built
with the existing assembly files and with gcc. At least at the moment.

> Nevertheless, it might be interesting if you test with the head of the
> development repository. 

I am heading there quickly. I just did a few tests of the mpfr release
candidate and it passes with flying colours. However, of course, mpfr
needs libgmp to pre-exist and thus it needs to be found in the right
place and I don't want the libs from anywhere else. So here I would tend
to use LD_RUN_PATH and "rpath" with gcc. Different things are needed on
ye c99/cc from Sun/Oracle.  However the Oracle/Sun folks tell me that
the latest compilers are really amazingly optimized for the latest big
sparc systems.  That would be the 4.1GHz SPARC M7 which I have at hand.
If I can get those assembly files to compile as is on that server and
then get reasonable libgmp performance from such a beast the next step
would be to see what can be done about an up to date gcc and then some
performance.

> A flag has been added that lessens the libtool
> machinery, maybe it's more robust than the current tarball given the
> flags you specify (but maybe not).

I will certainly head over there. It must be hg/svn/git or some cvs
based repo somewhere.

Dennis

ps: this all stems from my attempts to get a gcc compiler built
     https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg02494.html
     I am in to day 9 or 10 on this process.