On Sat, Aug 1, 2009 at 4:17 PM, Juan Jose Garcia-Ripoll<[email protected]> wrote: > > On Sun, Aug 2, 2009 at 12:50 AM, Dr. David > Kirkby<[email protected]> wrote: >> 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 >>>> 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.
Yes, that is the case. And whenever we have problems they get very quickly resolved. MPIR's Microsoft Windows support is also excellent (and we really hope ECL's will also be at some point). > 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. It is. I strongly encourage ECL to switch to using MPIR from GMP. If there are any issues that prevent this, please write the very friendly developers at http://mpir.org/. >> 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 > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
