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

[Emmanuel Thomé]

See there.

https://gmplib.org/devel/repo-usage.html

On Tue, Aug 29, 2017 at 08:06:30AM -0400, Dennis Clarke wrote:
> 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.

Ergo, you could drop that rpath.

I agree that when you want to rebuild everything and the kitchen sink as
a user, you have to use such things (or --with-foo=, or LDFLAGS, the
latter two being possibly better when viable). But as far as diagnosing a
possible misbehaviour goes, you should first take it out.

> 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 :

If you force the linker really hard on putting your target installation
directory first, you should be ready to face the problem that a
pre-existing library takes over. Which is exactly what is happening here.

Mpfr and gmp (up to 6.1.2) differ precisely in this aspect. See the
thread that vincent pointed to on this mailing list.

> 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.

Looks like Real Fun...

E.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Dennis Clarke]

[ 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 
#include 
#include 
#include 
#include 
#include 
#include 

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 

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

[Emmanuel Thomé]

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 ?

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.

Nevertheless, it might be interesting if you test with the head of the
development repository. 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).

E.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Vincent Lefevre]

On 2017-08-28 23:33:03 +0200, Niels Möller wrote:
> Vincent Lefevre  writes:
> > This only works if the user is root. If a non-root user wants to
> > install libraries in his home directory, the right solution is to
> > use LD_LIBRARY_PATH (since GCC doesn't use a run path by default).
> 
> You'd either use LD_LIBRARY_PATH, which is going to be a bit brittle
> when a build system or other script depends on using LD_LIBRARY_PATH for
> its own purposes,

They can preprend their own directories to $LD_LIBRARY_PATH.

> or compile the stuff needing the libraries with something like.
> 
>   LDFLAGS='-L $HOME/lib/ -Wl,-rpath,$HOME/lib'

which, in turn, may break things. For instance, MPFR uses LD_RUN_PATH
temporarily in its configure script. But if the user uses -rpath,
LD_RUN_PATH will be ignored. And I don't think we should re-implement
all the libtool machinery for the configure script to guess what
should work.

> Neither option is entirely painless, unfortunately.
> 
> In this particular case, it might work better if automake's test binary
> magic did use LD_LIBRARY_PATH and *pre*pended the .lib directory, but I
> guess it does things differently, either using -rpath or *a*ppending
> .lib. 

That's more a libtool thing than an automake one, AFAIK.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Dennis Clarke]

On 8/28/17 5:33 PM, Niels Möller wrote:

Vincent Lefevre  writes:


This only works if the user is root. If a non-root user wants to
install libraries in his home directory, the right solution is to
use LD_LIBRARY_PATH (since GCC doesn't use a run path by default).


I never build things as root. Or run tests. The install phase is done
as root of course and then I check the chmod/attr bits on the output.



You'd either use LD_LIBRARY_PATH, which is going to be a bit brittle



The LD_LIBRARY_PATH env var works as expected on Solaris systems just
as it should ( x86/sparc/POWER7 ? ) but I generally avoid it.



(I should probably not speculate more on exactly how it fails, but I'd
be happy to hear the precise explanation if someone here really knows
the automake magic involved).


I have no clue about automake incantations and spells. :-)

dc

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Niels Möller]

Vincent Lefevre  writes:

> This only works if the user is root. If a non-root user wants to
> install libraries in his home directory, the right solution is to
> use LD_LIBRARY_PATH (since GCC doesn't use a run path by default).

You'd either use LD_LIBRARY_PATH, which is going to be a bit brittle
when a build system or other script depends on using LD_LIBRARY_PATH for
its own purposes, or compile the stuff needing the libraries with
something like.

  LDFLAGS='-L $HOME/lib/ -Wl,-rpath,$HOME/lib'

Neither option is entirely painless, unfortunately.

In this particular case, it might work better if automake's test binary
magic did use LD_LIBRARY_PATH and *pre*pended the .lib directory, but I
guess it does things differently, either using -rpath or *a*ppending
.lib. 

I guess that the case of LD_LIBRARY_PATH pointing out a different
version of the libraries under test is broken/unsupported, or at least
isn't supported with the Solaris runtime linker.

(I should probably not speculate more on exactly how it fails, but I'd
be happy to hear the precise explanation if someone here really knows
the automake magic involved).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Vincent Lefevre]

On 2017-08-28 22:50:23 +0200, Niels Möller wrote:
> Dennis Clarke  writes:
> 
> > In some manner the pre-existing libs were getting in the way likely
> > because LD_LIBRARY_PATH=/usr/local/lib and thus the new libs in the
> > build_dir/.libs were not used.
> 
> LD_LIBRARY_PATH tends to override anything else. Don't use that for
> anything but to run specific binaries which need it.
> 
> Since this was a gnu/linux system, the usual way to make ld.so search
> /usr/local/lib is via files under /etc/ld.so.conf.d (even if that's
> system global, unlike LD_LIBRARY_PATH).

This only works if the user is root. If a non-root user wants to
install libraries in his home directory, the right solution is to
use LD_LIBRARY_PATH (since GCC doesn't use a run path by default).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Niels Möller]

Dennis Clarke  writes:

> In some manner the pre-existing libs were getting in the way likely
> because LD_LIBRARY_PATH=/usr/local/lib and thus the new libs in the
> build_dir/.libs were not used.

LD_LIBRARY_PATH tends to override anything else. Don't use that for
anything but to run specific binaries which need it.

Since this was a gnu/linux system, the usual way to make ld.so search
/usr/local/lib is via files under /etc/ld.so.conf.d (even if that's
system global, unlike LD_LIBRARY_PATH).

> Either way a symbol seems to have appeared because of the assembly
> files.

Right, precisely which internal functions get included in the library
depends on both platform and configure arguments.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Dennis Clarke]

This feels like a build test sequence issue as opposed to a bug of any
real sort.  I have pre-existing gmp libs installed in /usr/local from
yesterday and am doing a reconfigure and rebuild today. On a Debian 8.8
system 3.16.0-4-powerpc64 with gcc Debian 4.9.2-10 I see a complete
configure and compile thus :

ppc64$ ./configure ABI=mode64 --enable-cxx --prefix=/usr/local \
> --libdir=/usr/local/lib --build=powerpc970-unknown-linux-gnu
checking build system type... powerpc970-unknown-linux-gnu
checking host system type... powerpc970-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=mode64
checking compiler gcc -m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 
-maltivec -mfull-toc -mregnames ... yes
checking compiler gcc -m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 
-maltivec -mfull-toc -mregnames has sizeof(long)==8... yes

checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for gcc option to accept ISO C99... -std=gnu99
checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) 
-std=gnu99

checking how to run the C preprocessor... gcc -std=gnu99 -E
checking build system compiler gcc -std=gnu99... yes
checking for build system preprocessor... gcc -std=gnu99 -E
checking for build system executable suffix...
checking whether build system compiler is ANSI... yes
checking for build system compiler math library... -lm
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking C++ compiler g++  -m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 
-maltivec -mfull-toc -mregnames... yes

checking how to run the C++ preprocessor... g++ -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
using ABI="mode64"
  CC="gcc -std=gnu99"
  CFLAGS="-m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec 
-mfull-toc -mregnames"

  CPPFLAGS=""
  CXX="g++"
  CXXFLAGS="-m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec 
-mfull-toc -mregnames"
  MPN_PATH=" powerpc64/mode64/p4 powerpc64/p4 
powerpc64/mode64/p3-p7 powerpc64/p3-p7 powerpc64/mode64 powerpc64/vmx 
powerpc64 generic"

checking whether assembler supports --noexecstack option... no
checking for ar... ar
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc -std=gnu99... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert powerpc970-unknown-linux-gnu file names to 
powerpc970-unknown-linux-gnu format... func_convert_file_noop
checking how to convert powerpc970-unknown-linux-gnu file names to 
toolchain format... func_convert_file_noop

checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... dlltool
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 
object... ok

checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no
checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC
checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes
checking if gcc -std=gnu99 static flag -static works... yes
checking if gcc