[Ecls-list] Solaris SPARC issues with Sun complier - location of gmp specified.

Gabriel Dos Reis gdr at integrable-solutions.net
Sun Aug 2 15:05:14 UTC 2009


On Sun, Aug 2, 2009 at 4:41 AM, Juan Jose
Garcia-Ripoll<juanjose.garciaripoll at googlemail.com> wrote:
> On Sat, Aug 1, 2009 at 11:57 PM, Juan Jose
> Garcia-Ripoll<juanjose.garciaripoll at googlemail.com> wrote:
>> On Sat, Aug 1, 2009 at 11:36 PM, Dr. David
>> Kirkby<david.kirkby at onetel.net> wrote:
>>> Following from my mail half an hour or so ago, here is what happens on
>>> t2 if the Sun compiler is used, but the location of the gmp library and
>>> header files are specified.
>>> Undefined                       first referenced
>>>  symbol                             in file
>>> __gmpn_perfect_square_p             dpp.o
>>> __gmpz_tdiv_q                       dpp.o
>>> __gmpq_set                          dpp.o
>>> __gmpz_set                          dpp.o
>>> __gmpn_add_n                        dpp.o
>>> __gmpn_sub_n                        dpp.o
>>> __gmpn_popcount                     dpp.o
>>> ld: fatal: Symbol referencing errors. No output written to dpp
>>> I've seen very similar error messages about __gmp.... undefined, when
>>> using the GNU compiler too.
>>
>> Yes, I have seen this, and I can not tell what this is about. GMP is
>> not used or referenced in the dpp program at all and those symbols
>> should not be linked in. There must be a problem with the GMP headers
>> and the Solaris versions of the compiler or something like that.
>
> I found the problem: GMP has inline forms which are being compiled
> always, even if no function from GMP is used. See for instance gmp.h,
> line 1745 (below an exceprt). Somehow GCC is creating references to
> those functions _always_.
>
> This is absurd for GCC to do, specially since those inline functions

GCC is only following orders -- the orders may be stupid but it
is not GCC's fault.

> are not called anywhere in dpp.c Note that even with a hack to prevent
> including gmp.h in dpp.c, the problem persists because one will find
> multiple definitions of the same function.
>
> I will see whether MPIR has this problem.
>
> #if defined (__GMP_EXTERN_INLINE) || defined (__GMP_FORCE_mpz_set_q)
> #if ! defined (__GMP_FORCE_mpz_set_q)
> __GMP_EXTERN_INLINE
> #endif
> void
> mpz_set_q (mpz_ptr __gmp_w, mpq_srcptr __gmp_u)
> {
>  mpz_tdiv_q (__gmp_w, mpq_numref (__gmp_u), mpq_denref (__gmp_u));
> }
> #endif

The problem is with C notion of 'extern inline'.  It is not what you would
think it is.  If you use "static inline", GCC will not emit a reference
to the function if it is not referenced.

Note that is difference from C++ notion though (which is what you would think
it is.)

--- Gaby




More information about the ecl-devel mailing list