On Sun, Aug 2, 2009 at 12:50 AM, Dr. David Kirkby<david.kir...@onetel.net> wrote: > Juan Jose Garcia-Ripoll wrote: >> >> On Sat, Aug 1, 2009 at 11:36 PM, Dr. David >> Kirkby<david.kir...@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 >>> 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?
dpp is just a preprocessor for C code. It is used to translate the code that makes the core of ECL. It is very basic C, using at most fopen, fclose, strcpy, etc. I am thus surprised that the GMP symbols ever got linked in. > The libraries in /usr/local on 't2' have passed all self-tests and were > built with an ABI of 32. Ok, I presume that ECL should also be built with an ABI of 32 bits. I mean, the best thing would be to build exactly as the rest Sage > 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. GMP seems to be the stopper here, but from what you say thee replacement is building fine on all platforms that Sage supports. I would say the right thing would be to let ECL use that replacement. Eventually ECL might also evolve in the direction of using it: support for OSX and Windows seems complete in MPIR. > That builds headers and libraries with the name gmp (or at least can do). It > is 100% compatible version. This should do it: if the library names, headers and functions are identical, we do not need to change anything in ECL to use that replacement. > Inside Sage, the includes go to SAGE_LOCAL/local/include ,the libraries to > $SAGE_LOCAL/local/lib. Se we know EXACTLY where things are. Configure ECl using --with-system-gmp=yes CPPFLAGS=-I$SAGE_LOCAL/local/lib LDFLAGS=-L$SAGE_LOCAL/lib CFLAGS="..." LDFLAGS="..." where CFLAGS and LDFLAGS is an appropriate choice for the ABI that MPIR is using. Regarding sources, I would use the CVS tree. You can insert it in the Sage tree that you have. This way, if I make any changes, you will get them immediately and we can test different combinations. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
