[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