[Ecls-list] CVS build failure
Juan Jose Garcia-Ripoll
juanjose.garciaripoll at googlemail.com
Mon Aug 31 17:27:37 UTC 2009
On Mon, Aug 31, 2009 at 7:18 PM, Nils Bruin<nbruin at cecm.sfu.ca> wrote:
> For the last couple of days, when I try to build ecls from CVS I get the
> following errors in the link for eclmin:
>
> libeclmin.a(file.o): In function `ecl_make_string_output_stream':
> /scratch/nbruin/sage-newecl/spkg/build/ecl-9.8.4/src/src/c/file.d:1468:
>
> I assume these are deprecated functions that haven't been changed over yet,
> since unsetting NO_LEGACY does the trick. Is there an elegant way of enabling
> LEGACY (i.e., more elegant than "#undef ECL_NO_LEGACY" in external.h)?
This should have been fixed in CVS during the weekend. I will verify
that both source trees remain consistent, though.
> Are there guidelines on when to expect CVS to build?
Always ;-) Otherwise it is considered an error.
> * ECL currently assumes that GMP stores GMP_LIMB_BITS significant bits per
> limb. GMP stores GMP_NUMB_BITS in each limb. Most of the times, this is the
> same, but if GMP has "nails" configured (bits that can be used to handle
> carries more efficiently on some architectures), then GMP_NUMB_BITS can be
> smaller. See gmp.h and the code of init2 in gmp.
Yep, I take note, but as you said, it is just an orientation for a
register size which is not too large and which depends on the size of
the words of that machine. Using one or another does not change much.
> * In h/number.h, there are the lines:
>
> #else /* WITH_GMP */
> [...]
> #define _ecl_big_clear(x) mpz_clear((x)->big.big_num)
I will fix it, but I would say nobody uses --without-gmp these days.
Thanks for reporting these problems!
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
More information about the ecl-devel
mailing list