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.<br><br>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.<br>

<br>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.<br>

<br>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.<br>

<br>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".<br><br>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.<br>

<br>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<br>

    ecl -eval '(print (* 32 (round (/ (integer-length most-positive-fixnum) 32))))' -eval '(quit)'<br>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.<br>

<br>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.<br>

<br>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?<br>

<br>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>