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

[Juan Jose Garcia-Ripoll]

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




>> I suspect perhaps the configure script might do with a bit more
>> checking. It's quite possible people build gmp with one compiler, and tr
>> y try to build ecl with another. (I happen to know on 't2' that gmp in
>> /usr/local was built using the gcc compiler from /usr/sfw/bin/gcc, but
>> in general it would be good if you could detect some of the problems
>> that people might get. I suspect if the right options to configure are
>> used, this probably would build, but it far from easy to find out how.)
>
> Dave, I do not know whether you can grasp the level of frustration I
> have been feeling for the last two days. I do not know whether it is
> just Solaris or the settings or installed headers and compilers in the
> cluster, but this platform is a nightmare.
>
> There is a limit on the amount of magic I can push in the autoconf
> file. I know at some point Gabriel will pop up and say that one can
> not expect users to do or know anything, but if you have a machine
> where a library built with one compiler can not be used by another
> one, then, I am not going to be able to solve that by myself: whoever
> wants to build ECL will have to supply the right flags.
>
> Let me explain this GMP is a schizophrenic beast, and Solaris also.
> Solaris has lots of different modes to build a program, depending on
> whether you supply -m64 or not, -mptr64 or not and a couple more
> options. Libraries built in one mode are going to be incompatible with
> libraries built in different modes. ECL can not know what are the
> flags used for a pre-installed library in solaris, so if you want to
> use _that_ library you will have to go and find out the right CFLAGS
> and LDFLAGS to use. This is one reason why I can not use the
> preinstalled libraries in your clusters. The header problems above is
> another one.
>
> The other option is to let ECL build GMP itself. This is what I have
> been doing so far. We still have a problem with multiple options, but
> this can be alleviated by letting GMP choose the flags itself and then
> copying them. That is why the flag --enable-slow-config was introduced
> 6 or more years ago (notice how http://ecls.sf.net/logs.html lists the
> flags I used: other combinations might not be supported). With that
> flag ECL configures GMP and copies CFLAGS and LDFLAGS from the library
> to build a version of ECL that is compatible with it.
>
> That said, I keep investigating whether there are other options for
> building ECL on the Solaris platform. GMP 4.3.1 does not seem to solve
> the problems with Intel, but rather introduce new ones. Again, I am
> not sure whether this is a problem with stock Solaris, or with your
> particular installation.
>
> Juanjo
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://juanjose.garciaripoll.googlepages.com
>



-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com