On Sat, Aug 1, 2009 at 3:50 PM, Dr. David Kirkby<[email protected]> wrote:
>
> Hi,
>
> I copied this to sage-devel too, as clearly ECL is important. (For
> anyone else, this discussion started on [email protected]).
>
> Juan Jose Garcia-Ripoll wrote:
>> On Sat, Aug 1, 2009 at 11:36 PM, Dr. David
>> Kirkby<[email protected]> 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.
>
> Is dpp part of ECL or one of the libraries?
>
>>> 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.
If you're developing on skynet then you should do the following (which
I do in my .bash_profile):
source /home/wstein/bin/skynet_bash_profile-4.4.0
if [ `hostname` = "mark" ]; then
PATH=/usr/local/bin/sparc-SunOS-ultrasparc3/:$PATH
fi
I've made my /home/wstein/bin world readable (hopefully).
>
> I can see you are frustrated. You have clearly put a lot of effort into
> this, and I'm sure the Sage team appreciate this.
>
> Most code tends to be developed on linux boxes, and a lot of people
> (unlike yourself) can't be bothered to test on Solaris. Yet Solaris is a
> certified UNIX operating system.
>
>> 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.
>
> In general, using a library built by one compiler with another compiler
> should present no problems. Trying to build 32-bit libraries, while
> linking in 64-bit headers will cause problems, but that is not this
> issue here.
>
> On Solaris, the directory /usr/lib contains 32-bit libs, and /usr/lib/64
> contains the 64-bit versions. But a user should not need to know that.
> The compiler should chose the right ones automatically.
>
>> 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.
Sage ships its own GMP (actually MPIR), and if you an provide the
right flags for us to use (documented somewhere), then I'll be happy.
>
> The libraries in /usr/local on 't2' have passed all self-tests and were
> built with an ABI of 32.
>
> However, since Sage uses a huge range of things, it just includes
> *everything* needed - including a replacement for GMP. So we are not
> actually using GMP.
>
>> 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 could work for Sage. The ECL spkg could use the flags that our
GMP (actually MPIR) happened to use.
> I looked at http://ecls.sf.net/logs.html and see for 'FLAGS' 'Defaults'.
> Unfortunately, without knowing how the system was configured, it's not
> possible to know what 'defaults' would be used. Since a default install
> of Solaris will not have GMP.
>
> Inside Sage, GMP is not used, but MPIR (not IPIR as I erroneously wrote
> in that email).
>
> http://www.mpir.org/
>
> That builds headers and libraries with the name gmp (or at least can
> do). It is 100% compatible version.
>
> It's possible that the changes you have made, may allow ECL to build
> inside sage, where is uses MPIR and not GMP. I could download the latest
> CVS, make a new package and test that.
>
> Inside Sage, the includes go to SAGE_LOCAL/local/include ,the libraries
> to $SAGE_LOCAL/local/lib. Se we know EXACTLY where things are.
>
> I think you are basically saying you do the same. Build the library
> yourself, then you know where it is, what options it was built with etc.
>
>> 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
>
> If you could either
>
> a) Give me a ecl.tar.gz which you think gives us the best chance or
>
> b) Suggest I download from CVS (I just installed cvs on 't2' tonight),
> then I can have a go at building this inside sage, where the exact
> versions and locations are known.
>
> and tell me what flags you used to build it, then I can try to replicate
> them inside Sage, where the GMP in /usr/local/lib and /usr/local/include
> is not used at all.
>
> I really do see your frustration. If there is anything you can think of
> that I could do to relieve some of that, let me know. I'm happy to try
> anything you suggest.
>
> I've been away from Sage a bit for a few days, as I suffered lightning
> damage to several computers. I'm gradually moving hardware around, and
> have at least some sort of normality now.
>
>
> Dave
William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
