assembly files on Solaris SPARC can only be processed with gcc

[Niels Möller]

Dennis Clarke <dclarke at blastwave.org> 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  tag                value
>        [0]  NEEDED            0x19fd              libgmp.so.10
>        [1]  NEEDED            0x1980              libstdc++.so.6
>        [2]  NEEDED            0x1a0a              libm.so.2
>        [3]  NEEDED            0x1a14              librt.so.1
>        [4]  NEEDED            0x19c4              libgcc_s.so.1
>        [5]  NEEDED            0x19da              libc.so.1
>        [6]  INIT              0x51c8
>        [7]  FINI              0x51e4
>        [8]  SONAME            0x1a1f              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  tag                value
>        [0]  NEEDED            0x28f5              libgcc_s.so.1
>        [1]  NEEDED            0x290b              libc.so.1
>        [2]  INIT              0x5f530
>        [3]  FINI              0x5f54c
>        [4]  SONAME            0x2927              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.