Dennis Clarke <dcla...@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. _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs