<div class="gmail_quote">On Sun, Jan 2, 2011 at 10:54 AM, Gabriel Dos Reis <span dir="ltr"><<a href="mailto:gdr@integrable-solutions.net">gdr@integrable-solutions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":fu">On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll<br>
<div class="im"><<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>> wrote:<br>
<br>
</div><div class="im">> This seems to be the current attitude in the Autoconf'ed world, where<br>
> uniform build environments are assumed and deviations from them are a<br>
> responsibility of the packager or builder.<br>
<br>
</div>I don't know what you mean by that. I don't recall that the GMP library<br>
is supposed to be linked against only in a uniform build environments, nor<br>
do I understand why that has to be assumed (in this specific case.)<br></div></blockquote></div><br>What I mean is that right now I am using prepackaged software built with standard compiler flags. Developers provide the basic software and port maintainers keep track of how the build/compile/link flags of their platform evolve and pass those to their libraries, compilers, editors, etc, using standard Autoconf techniques. That provides a "uniform" environment in which the developer of a piece of software is isolated from the complexities of the platforms in which it is delivered, as far as standard features (POSIX, C, math, etc) are concerned, of course. It also may safely expect that all software is properly installed and binary compatible.<div>
<br></div><div>That is how I expected ECL to be used and so far I have not received any feedback that this mode of use makes it totally useless and impossible to integrate in reasonable software. Where particular needs had to be met, the configuration mechanism is flexible enough that developers may provide nonstandard build and link options *in their private copies*, and be consistent then with their own software.</div>
<div><br></div><div>We should put also things in perspective. What do other lisps really provide? Lisps around are not that smart and might fool you. If I take my copy of SBCL the *features* it supplies are just names of assembler backends. From base-target-features.lisp-expr</div>
<div><div> ;; machine architecture features:</div><div> ;; :x86 any Intel 386 or better, or compatibles like the AMD K6 or K7</div><div> ;; :x86-64 any x86-64 CPU running in 64-bit mode</div><div> ;; :alpha; DEC/Compaq Alpha CPU</div>
<div> ;; :sparc any Sun UltraSPARC (possibly also non-Ultras -- currently untested)</div><div> ;; :ppc any PowerPC CPU</div><div> ;; :hppa any PA-RISC CPU</div><div> ;; :mips any MIPS CPU (in little-endian mode with :little-endian)</div>
</div><div><br clear="all">Note how this is incomplete. You can not deduce from here how C software has to be built and linked to be properly loaded and used by SBCL. This is ultimately confirmed by looking at the features of the Solaris/Sparc copy that is installed in Sage's buildnet (v 1.0.17). It does not offer really useful hints about what ABI it uses<div>
<br></div><div><div>(:ANSI-CL :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS</div><div> :SB-UNICODE :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :SPARC :UNIX</div><div> :ELF :SUNOS :LINKAGE-TABLE :STACK-ALLOCATABLE-CLOSURES :OS-PROVIDES-DLOPEN</div>
<div> :OS-PROVIDES-DLADDR :OS-PROVIDES-PUTWC :OS-PROVIDES-BLKSIZE-T</div><div> :OS-PROVIDES-SUSECONDS-T)</div></div><div><br></div><div>On looking at other platforms, the number of combinations are always limited. The implementation that excels at providing information is Lispworks, which has <a href="http://www.lispworks.com/documentation/lw60/LW/html/lw-600.htm#marker-1039551">http://www.lispworks.com/documentation/lw60/LW/html/lw-600.htm#marker-1039551</a> with :lispworks-32bit and :lispworks-64bit and a total of 14 combinations perfectly documented -- what those combinations imply for the C world, though, is left to the user.</div>
<div><br></div><div>Other platforms, such as CCL have no documented features but seem to offer a name for the backend -- which I can not guess from their web.</div><div><br></div><div>OpenAxiom also takes two different approaches when it comes to GCL. From /open-axiom.trunk/config/open-axiom.m4</div>
<div>## For all values of L, except gcl, the assumption is that the Lisp</div><div><div>## image L is available in the build environment. For gcl,</div><div>## we make an exception: if no GCL image is available, or if</div>
<div>## the option --enable-gcl is specified then OpenAxiom builds its </div><div>## own version from the source tree.</div></div><div>So OpenAxiom contemplates and does build GCL from sources providing it with the right compiler flags (the default ones plus optimizations) and <b>guessing the "openaxiom_precision" from the C compiler itself</b>.</div>
<div><br></div><div>When preinstalled, <b>GCL itself will only supply OpenAxiom with the host_cpu value given by Autoconf</b>, which is <b>what ECL is currently doing,</b> so it would suffer the same problem when trying to identify the appropriate binary format in OS X -- I say "would" because I have not been able to build GCL myself.</div>
<div><br></div><div>So put in perspective, some of the lisps out there provide information for the limited number of platforms they support, some of them do not provide enough.</div><div><br></div><div>Could ECL do better? But what?</div>
<div><br></div><div>To sort out this discussion I may just add a single keyword called :ecl-32bit-pointers and :ecl-64bit-pointers which will denote the size of pointers. This will be equivalent to doing the following in OA's configuration</div>
<div><br></div><div>if test "$axiom_lisp_flavor" = ecl; then</div><div> openaxiom_host_lisp_precision=`ecl -eval '(print (* 8 (ffi:size-of-foreign-type :pointer-void)))' -eval '(quit)'`</div><div>
fi</div><div><br></div><div>But will it match the logic after that that OpenAxiom uses to determine compiler flags?</div><div><br></div><div><div>## Augment C and C++ compiler flags with ABI directives as appropriate</div>
<div>## before we proceed to infer other host datatype properties.</div><div>if test -n "$openaxiom_host_lisp_precision"; then</div><div> case $GCC in</div><div> yes)</div><div> CPPFLAGS="$CPPFLAGS -m$openaxiom_host_lisp_precision"</div>
<div> LDFLAGS="$LDFLAGS -m$openaxiom_host_lisp_precision"</div><div> ;;</div><div> no)</div><div> # cross fingers and pray.</div><div> ;;</div><div> esac</div><div>fi</div></div><div>
<br></div><div>Well, this I can not assure.</div><div><br></div><div>But as I said privately, even the -m32/-m64 option that OpenAxiom is using might not be enough to make the software compatible with a preinstalled ECL. What if other compilers are used? Take a Linux/PPC with IBM's toolchain. I may choose to build ECL using xlc and 128-bit long double, or 64-bit ones, or ones that are library compatible or ones that are not. This will affect how your software interacts with ECL. I would expect that other options, such as the thread-local-storage might as well, but I do not know enough about this and I would rather remain isolated from that -- is this really a fool's choice?</div>
<div><br></div><div>Juanjo</div><div><br></div>-- <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>
</div>