[Ecls-list] Help needed, really

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Thu Dec 30 09:42:43 UTC 2010


I am having a now too long discussion about things that ECL should or should
not do and I really need help, someone that translates or helps me
understand this because we are not getting anywhere.

The original problem was that OpenAxiom was not building right in OS X
because it expects ECL to export some keyword saying :x86-64 or something
like that and from that infer the appropriate compiler flags. ECL relies on
Autoconf and is only exporting the host name that it provides, which is
i686. Since ECL does not really care about the processor type, it is fine
with it, and just works: it only relies on information provided by the
compiler, such as type sizes, alignments, and the like, which are found at
compilation time.

Right now ECL's philosophy is not to know anything about the platform it
runs on beforehand. The way it is configured is left up to the user, who may
choose via CFLAGS/LDFLAGS what architecture, build mode or, to say something
more technical, ABI, it wants to run on. The reason for this choice is that
I had and have to build ECL on platforms that allow at least three build
modes, with varying sizes of ints, longs and pointers, and this leads to
incompatible binaries -- the responsibility is thus on the software packager
or distributor to provide uniform flags across a platform. The other reason
is that I do not have time to maintain knowledge about all the platforms
that ECL might run on, all compatible compiler flags, and the different
build modes (ABIs) that they support.

The only thing that ECL does to alleviate this problem is to export the
compiler flags in "ecl-config" so that people may build software that can be
linked against ECL in that way, but ECL just gathers this information from
the user's CFLAGS/LDFLAGS, nothing cleverer.

Now OpenAxiom is requesting from ECL one piece of information: the ABI. For
some reason it is not an option to use "ecl-config --cflags".

I sincerely have no idea how to provide this ABI stuff. The only pieces of
information that ECL has are C integer sizes (EXT:C-UINT-MAX,
EXT:C-ULONG-MAX, etc) If someone may infer the appropriate ABI name and
compiler flags from it, then it is ok, but I do not know how to get that.

Alternatively I am being asked to provide whether ECL is built with 64-bits
or 32-bits. I argue that this information is not enough to infer compiler
flags, for some platforms do provide more than two choices (different 32-bit
modes, different 64-bit modes, incompatible among them). Furthermore what
ECL does is simply to choose the largest integer that fits a pointer and
work with that as a fixnum, be it int, long or long long. So there is no
notion of 64-bit or 32-bit, it is just what the system gives, and I am not
sure that this may be used to identify the ABI. If it does, it can be
gathered in a simple way
    ecl -eval '(print (* 32 (round (/ (integer-length most-positive-fixnum)
32))))' -eval '(quit)'
I understand that this solution is rejected because I am asked to offer a
100% relation between this number and the ABI which, as I said, I do not
feel comfortable to do that.

It has been repeatedly argued that ECL does know the ABI and that all we are
doing is hiding it and producing an uncooperative library that does not
allow itself to be properly linked against other software. This is not the
image I want to transmit and as you may argue I have no intention to be
resistive against futher uses of ECL, but I sincerely do not know what I am
expected to do.

It is frustrating, end of the year is coming and I am tired. So please,
would somebody more knowledgeable step in and "translate" this conversation
or just tell precisely what I have to add to ECL? Or even better, do it
themselves?

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20101230/515359fb/attachment.html>


More information about the ecl-devel mailing list