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

[Juan Jose Garcia-Ripoll]

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