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: assembly files on Solaris SPARC can only be processed with gcc

[Niels Möller]

Dennis Clarke  writes:

> somedays I don't include details and I get railed at .. other days I
> do and I get railed at .. life goes on.

Including details is nice and helpful, just don't expect everyone to
digest all of the details at once. If I spot a single small problem in
what you report, I might be able to provide some help on that, even if I
don't have a good idea of the big picture.

>> 2. GMP's Makefiles are not expected to try to do that; if they do on
>> your platform, we'd need to figure out why.
>
> sorry .. lost me there.

I'll try to clarify. The Makefiles are expected to run roughly the two
commands

   m4 ... foo.asm > foo.s
   $(CC) ... foo.s -o foo.o

for each used .asm file. If you observe make trying to run

   $(CC) ... foo.asm -o foo.o

instead, then you have found a severe Makefile-related problem. "can
only be preprocessed with gcc" sounded like you expected the above
incorrect command to somehow succeed in case CC=gcc, and break only if
gcc is replaced by Oracles compiler. But it's broken regardless of
compiler; the separate m4 step is always required.

Do you follow?

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: assembly files on Solaris SPARC can only be processed with gcc

[Dennis Clarke]

On 8/28/17 5:36 PM, Torbjörn Granlund wrote:

Dennis Clarke  writes:

   somedays I don't include details and I get railed at .. other days I
   do and I get railed at .. life goes on.
   
Did Niels rail you?  I think that's a quite unfair assessment.  He's


no ... I jsut know that I can be verbose. isn't the first time.


pointing out a central issue here, your snub is the attitude problem
here, if any.


yep



(To iterate and ask for more information is normal in any softwware help
situation.  To take such requests as critique is probably not the best
strategy.)


I'm just trying to figure out how to squeeze some performance out of a 
few weird processor types.


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

[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: assembly files on Solaris SPARC can only be processed with gcc

[Torbjörn Granlund]

Dennis Clarke  writes:

  somedays I don't include details and I get railed at .. other days I
  do and I get railed at .. life goes on.
  
Did Niels rail you?  I think that's a quite unfair assessment.  He's
pointing out a central issue here, your snub is the attitude problem
here, if any.

(To iterate and ask for more information is normal in any softwware help
situation.  To take such requests as critique is probably not the best
strategy.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
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: assembly files on Solaris SPARC can only be processed with gcc

[Dennis Clarke]

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

Dennis Clarke  writes:


On 8/28/17 4:41 PM, Niels Möller wrote:

Dennis Clarke  writes:




The compiler sees that file gcd_1.asm as something unknown.


That command is bogus.


I think you missed the point.


Then please enlighten me? I'm trying to help, even though I have to
admit that I didn't read carefully all of your 1000+ lines email. My
points are that


somedays I don't include details and I get railed at .. other days I do 
and I get railed at .. life goes on.




1. Invoking any compiler with $(CC) ... -o foo.o foo.asm, like the
failing command you showed, is not expected to work.


yep .. I would think a foo.s is what is needed and as you say m4 had to
 pre-process the input from somewhere else first.



2. GMP's Makefiles are not expected to try to do that; if they do on
your platform, we'd need to figure out why.


sorry .. lost me there.




That libgmpxx depends on libstdc++ is perfectly normal ..


Yes, if gcc is used then you end up with these dependencies.
That doesn't happen with the Oracle Studio 12.5 dev tools compilers.


To clarify, I'd expect libgmpxx to depend on the C++ standard library
supplied with the compiler used to build gmp.


This is all that is left as NEEDED in the output final libs :

v9_7++ $ elfdump -devl  /usr/local/lib/libgmp.so.10.3.2 | grep "NEED"
   [0]  NEEDED0x2c4f  libc.so.1
  [12]  VERNEED   0x8520
  [13]  VERNEEDNUM0x1

v9_7++ $ elfdump -devl /usr/local/lib/libgmpxx.so.4.5.2 | grep "NEED"
   [0]  NEEDED0x229f  libgmp.so.10
   [1]  NEEDED0x2283  libc.so.1
  [13]  VERNEED   0x3d20
  [14]  VERNEEDNUM0x1

Very minimal.  Very very terribly slow.


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

Re: assembly files on Solaris SPARC can only be processed with gcc

[Dennis Clarke]

On 8/28/17 5:01 PM, Marc Glisse wrote:

On Sun, 27 Aug 2017, Dennis Clarke wrote:


I have been trying to get gmp-6.1.2 to build while avoiding the use of
"disable-assembly" in the configure stage. I think I may have tripped on
something here.  So I isolated everything into my home dir and gave it
a try.  Mostly trying to get some decent performance.


If you care about performance, use gcc to compile GMP. The only good
reason to compile GMP with studio is for gmpxx for ABI reasons.



Yep. I was thinking consistency across a whole toolchain wherein gcc has
not been used and there are no dependencies on libgcc or its brethern.


Configure looks fine thus :

v9_7++ $ ./configure ABI=64 --enable-cxx \

--prefix=/export/home/dclarke/local \
--libdir=/export/home/dclarke/local/lib \


that libdir is redundant.


I figured .. left it in there for years.  gone now.




--build=sparc64-sun-solaris2.10


so you are explicitly trying to disable some optimizations?

checking compiler /opt/developerstudio12.5/bin/c99 -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc -I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE... yes




First past .. yes. However I go back and reset those flags to enable
optimizations and remove the debug data. However, I sort of wanted the
debug data and the ability to single step along. It has to be a trade
off with debug libs residing somewhere else I guess.



gmake[2]: *** [Makefile:768: gcd_1.lo] Error 1


this isn't giving any hint as to what the error is :-(


yep .. I was told that m4 needs to pre-process those asm files and we
 should get output foo.s files.


  Should I even care?


No (to the last question).


Let me think on that.




Better than before but a 12 year old PowerMac G5 does the same job in
just about 3.5 secs. An AMD Opteron at 3GHz does it all faster than 
that and I hear from Paul Zimmermann that his laptop is sub-second. 
Not sure

how to get some performance out of libgmp on this platform.  Am really
open to any thoughts.


If you care about GMP performance, don't use sparc... 


I have access to a M7 based 4.1GHz system. It is fairly amazing in terms
of pure speed.  However it can not be had unless the Oracle compilers
are used.

$ fpversion
 A SPARC-based CPU is available.
 Kernel says CPU's clock rate is 4133.2 MHz.

 Sun-4 floating-point controller version 0 found.
 An UltraSPARC chip is available.

 Use "-xtarget=M7 -xcache=16/32/4/8:256/64/8/16:8192/64/8/32" 
code-generation option.


 Hostid = 0x865DA634.
$

$ file pi6_256M
pi6_256M: ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC3 
Extensions Required [CBCOND VIS3], dynamically linked, not stripped

$

$ which openssl
/usr/ccs/bin/openssl
$ openssl speed sha512
Doing sha512 for 3s on 16 size blocks: 18525471 sha512's in 2.99s
Doing sha512 for 3s on 64 size blocks: 20462241 sha512's in 3.00s
Doing sha512 for 3s on 256 size blocks: 11174149 sha512's in 3.00s
Doing sha512 for 3s on 1024 size blocks: 4919522 sha512's in 3.00s
Doing sha512 for 3s on 8192 size blocks: 791410 sha512's in 3.00s
OpenSSL 1.0.1p 9 Jul 2015
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,int) des(ptr,risc1,16,int) 
aes(partial) blowfish(ptr)

compiler: information not available
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
bytes
sha512   99132.96k   436527.81k   953527.38k  1679196.84k 
2161076.91k

$

I don't know what good numbers are but that looks good.  There has
been a ton of money poured into the sparc platform in recent years and
the result is a fairly staggering system.  I think Rainer Orth has done
some work with gcc therein also but the Oracle Studio compilers are the
ones that are built to take advantage of these chips. So the marketing
goes.  :-\

Anyways, whatever it is these assembly files bring to the table may be
rocket science and I was merely trying to get gmp builds, reasonable
builds, across a whole suite of platforms. SPARC is a lot of things but
it isn't dead.

Dennis
___
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: assembly files on Solaris SPARC can only be processed with gcc

[Marc Glisse]

On Sun, 27 Aug 2017, Dennis Clarke wrote:


I have been trying to get gmp-6.1.2 to build while avoiding the use of
"disable-assembly" in the configure stage. I think I may have tripped on
something here.  So I isolated everything into my home dir and gave it
a try.  Mostly trying to get some decent performance.


If you care about performance, use gcc to compile GMP. The only good
reason to compile GMP with studio is for gmpxx for ABI reasons.


Configure looks fine thus :

v9_7++ $ ./configure ABI=64 --enable-cxx \

--prefix=/export/home/dclarke/local \
--libdir=/export/home/dclarke/local/lib \


that libdir is redundant.


--build=sparc64-sun-solaris2.10


so you are explicitly trying to disable some optimizations?

checking compiler /opt/developerstudio12.5/bin/c99 -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none 
-Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc 
-I/export/home/dclarke/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE... yes


I know those are the flags that you are using elsewhere, but the first
thing to try is always to remove all your special stuff.

libtool: compile:  /opt/developerstudio12.5/bin/c99 -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_perfpow 
-I/export/home/dclarke/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -errfmt=error -erroff=%none -errshort=full -xstrconst 
-xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf 
-xunroll=1 -xarch=sparc -c perfpow.c  -KPIC -DPIC -o .libs/perfpow.o

"../gmp-impl.h", line 3701: warning:  attribute "mode" is unknown, ignored
"../gmp-impl.h", line 3702: warning:  attribute "mode" is unknown, ignored
"../gmp-impl.h", line 3703: warning:  attribute "mode" is unknown, ignored
"../gmp-impl.h", line 3704: warning:  attribute "mode" is unknown, ignored
"../gmp-impl.h", line 3705: warning:  attribute "mode" is unknown, ignored
libtool: compile:  /opt/developerstudio12.5/bin/c99 -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_perfpow 
-I/export/home/dclarke/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -errfmt=error -erroff=%none -errshort=full -xstrconst 
-xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf 
-xunroll=1 -xarch=sparc -c perfpow.c -o perfpow.o >/dev/null 2>&1
/usr/local/bin/bash ../libtool --mode=compile --tag=CC ../mpn/m4-ccas 
--m4="/usr/local/bin/m4" /opt/developerstudio12.5/bin/c99 -c -DHAVE_CONFIG_H 
-I. -I..  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo gcd_1 | sed 's/_$//'` 
-I/export/home/dclarke/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE  -errfmt=error -erroff=%none -errshort=full -xstrconst 
-xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf 
-xunroll=1 -xarch=sparc  `test -f 'gcd_1.asm' || echo './'`gcd_1.asm
libtool: compile:  ../mpn/m4-ccas --m4=/usr/local/bin/m4 
/opt/developerstudio12.5/bin/c99 -c -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 
-I/export/home/dclarke/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -errfmt=error -erroff=%none -errshort=full -xstrconst 
-xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf 
-xunroll=1 -xarch=sparc gcd_1.asm  -KPIC -DPIC -o .libs/gcd_1.o
/usr/local/bin/m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_gcd_1 
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DPIC gcd_1.asm 

tmp-gcd_1.s
/opt/developerstudio12.5/bin/c99 -c -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 
-I/export/home/dclarke/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -errfmt=error -erroff=%none -errshort=full -xstrconst 
-xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf 
-xunroll=1 -xarch=sparc tmp-gcd_1.s -KPIC -DPIC -o .libs/gcd_1.o
libtool: compile:  ../mpn/m4-ccas --m4=/usr/local/bin/m4 
/opt/developerstudio12.5/bin/c99 -c -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 
-I/export/home/dclarke/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -errfmt=error -erroff=%none -errshort=full -xstrconst 
-xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf 
-xunroll=1 -xarch=sparc gcd_1.asm -o gcd_1.o >/dev/null 2>&1

gmake[2]: *** [Makefile:768: gcd_1.lo] Error 1


this isn't giving any hint as to what the error is :-(

Re: assembly files on Solaris SPARC can only be processed with gcc

[Dennis Clarke]

On 8/28/17 4:41 PM, Niels Möller wrote:

Dennis Clarke  writes:




The compiler sees that file gcd_1.asm as something unknown.


That command is bogus.


I think you missed the point.

That libgmpxx depends on libstdc++ is perfectly normal .. 


Yes, if gcc is used then you end up with these dependencies.
That doesn't happen with the Oracle Studio 12.5 dev tools compilers.
Either way the point is academic as one can not build gmp and use those
assembly tweaks with anything else other than gcc. So perhaps this is
a build process issue wherein m4 is not being called correctly to
output the needed asm source foo.s files.

Dennis
___
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

Re: assembly files on Solaris SPARC can only be processed with gcc

[Niels Möller]

Dennis Clarke  writes:

> Just going into mpn directory and re-running that last compile command
> gives me an obvious error :
>
> v9_7++ $ c99 -c -DHAVE_CONFIG_H -I. -I.. \
>> -D__GMP_WITHIN_GMP -DOPERATION_gcd_1 \
>> -I/export/home/dclarke/local/include \
>> -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE \
>> -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 \
>> -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee \
>> -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf \
>> -xunroll=1 -xarch=sparc -o gcd_1.o gcd_1.asm
> c99: No valid input files specified, no output generated
> v9_7++ $
>
> The compiler sees that file gcd_1.asm as something unknown.

That command is bogus. The .asm files are supposed to be preprocessed
with m4, producing a .S file, before they're fed to the compiler. If
make really tried to run that command, something has gone wrong with the
make rules. Maybe try if it makes a difference using GNU make?

Or have you forgotten make distclean before running configure with new
args; that might leave the build directory in an invalid state?

> libgmpxx.so.4.5.2 says  --->
> Dynamic Section:  .dynamic
>  index  tagvalue
>[0]  NEEDED0x19fd  libgmp.so.10
>[1]  NEEDED0x1980  libstdc++.so.6
>[2]  NEEDED0x1a0a  libm.so.2
>[3]  NEEDED0x1a14  librt.so.1
>[4]  NEEDED0x19c4  libgcc_s.so.1
>[5]  NEEDED0x19da  libc.so.1
>[6]  INIT  0x51c8
>[7]  FINI  0x51e4
>[8]  SONAME0x1a1f  libgmpxx.so.4
>[9]  RUNPATH   0x1a2d
> /export/home/dclarke/local/lib:/usr/local/gcc7/lib/sparcv9
>   [10]  RPATH 0x1a2d
> /export/home/dclarke/local/lib:/usr/local/gcc7/lib/sparcv9
>
>
> Also for libgmp.so.10.3.2 we see :
>
> Dynamic Section:  .dynamic
>  index  tagvalue
>[0]  NEEDED0x28f5  libgcc_s.so.1
>[1]  NEEDED0x290b  libc.so.1
>[2]  INIT  0x5f530
>[3]  FINI  0x5f54c
>[4]  SONAME0x2927  libgmp.so.10
>[5]  RUNPATH   0x2934 /export/home/dclarke/local/lib
>[6]  RPATH 0x2934 /export/home/dclarke/local/lib
>
> So dependencies on libstdc++.so.6 and libgcc_s.so.1 there.

That libgmpxx depends on libstdc++ is perfectly normal, since that's the
library intended for C++ programs using the C++ glue to gmp. And libgmp
doesn't depend on libstdc++, also as expected.

libgcc_s.so is normal for anything compiled with gcc. I think it's
possible to force gcc to link it statically, but that's discouraged by
the gcc people. I haven't tried to really understand the pros and cons.

Anyway, gmp uses plain libtool for the shared libraries, so if anything
really is fishy with how they are produced, that's most likely a libtool
problem.

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

assembly files on Solaris SPARC can only be processed with gcc

[Dennis Clarke]

I have been trying to get gmp-6.1.2 to build while avoiding the use of
"disable-assembly" in the configure stage. I think I may have tripped on
something here.  So I isolated everything into my home dir and gave it
a try.  Mostly trying to get some decent performance.

Configure looks fine thus :

v9_7++ $ ./configure ABI=64 --enable-cxx \
> --prefix=/export/home/dclarke/local \
> --libdir=/export/home/dclarke/local/lib \
> --build=sparc64-sun-solaris2.10
checking build system type... sparc64-sun-solaris2.10
checking host system type... sparc64-sun-solaris2.10
checking for a BSD-compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... /usr/local/bin/gawk
checking whether /usr/local/bin/gmake sets $(MAKE)... yes
checking whether /usr/local/bin/gmake supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=64
checking compiler /opt/developerstudio12.5/bin/c99 -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc -I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE... yes
checking compiler /opt/developerstudio12.5/bin/c99 -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc has sizeof(long)==8... yes

checking for gcc... /opt/developerstudio12.5/bin/c99
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... no
checking whether /opt/developerstudio12.5/bin/c99 accepts -g... yes
checking for /opt/developerstudio12.5/bin/c99 option to accept ISO 
C89... none needed
checking whether /opt/developerstudio12.5/bin/c99 understands -c and -o 
together... yes
checking for /opt/developerstudio12.5/bin/c99 option to accept ISO 
C99... none needed
checking for /opt/developerstudio12.5/bin/c99 option to accept ISO 
Standard C... (cached) none needed
checking how to run the C preprocessor... 
/opt/developerstudio12.5/bin/c99 -E

checking build system compiler /opt/developerstudio12.5/bin/c99... no
checking build system compiler /opt/developerstudio12.5/bin/c99 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 
-xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc -I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE... yes
checking for build system preprocessor... 
/opt/developerstudio12.5/bin/c99 -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc 
-xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy 
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc 
-I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -E

checking for build system executable suffix...
checking whether build system compiler is ANSI... yes
checking for build system compiler math library... -lm
checking whether we are using the GNU C++ compiler... no
checking whether /opt/developerstudio12.5/bin/CC accepts -g... yes
checking C++ compiler /opt/developerstudio12.5/bin/CC 
-I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -dalign -erroff=%none 
-errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 
-xbuiltin=%none -xarch=sparc -xdepend=no -xnolibmopt -xlinkopt=0 
-xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -D_TS_ERRNO... yes
checking how to run the C++ preprocessor... 
/opt/developerstudio12.5/bin/CC -E

checking for grep that handles long lines and -e... /usr/local/bin/grep
checking for egrep... /usr/local/bin/grep -E
using ABI="64"
  CC="/opt/developerstudio12.5/bin/c99"
  CFLAGS="-errfmt=error -erroff=%none -errshort=full -xstrconst 
-xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none 
-xdebugformat=dwarf -xunroll=1 -xarch=sparc"
  CPPFLAGS="-I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE"

  CXX="/opt/developerstudio12.5/bin/CC"
  CXXFLAGS="-dalign -erroff=%none -errtags=yes -ftrap=%none -g 
-xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xarch=sparc 
-xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs 
-D_POSIX_PTHREAD_SEMANTICS 

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