assembly files on Solaris SPARC can only be processed with gcc

Niels Möller nisse at
Mon Aug 28 20:41:02 UTC 2017

Dennis Clarke <dclarke at> 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.. \
>> -I/export/home/dclarke/local/include \
>> -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?

> says .... --->
> Dynamic Section:  .dynamic
>      index  tag                value
>        [0]  NEEDED            0x19fd    
>        [1]  NEEDED            0x1980    
>        [2]  NEEDED            0x1a0a    
>        [3]  NEEDED            0x1a14    
>        [4]  NEEDED            0x19c4    
>        [5]  NEEDED            0x19da    
>        [6]  INIT              0x51c8
>        [7]  FINI              0x51e4
>        [8]  SONAME            0x1a1f    
>        [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 we see :
> Dynamic Section:  .dynamic
>      index  tag                value
>        [0]  NEEDED            0x28f5    
>        [1]  NEEDED            0x290b    
>        [2]  INIT              0x5f530
>        [3]  FINI              0x5f54c
>        [4]  SONAME            0x2927    
>        [5]  RUNPATH           0x2934 /export/home/dclarke/local/lib
>        [6]  RPATH             0x2934 /export/home/dclarke/local/lib
> So dependencies on and 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. 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


Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

More information about the gmp-bugs mailing list