[Ecls-list] Help needed, really

Sun Jan 2 18:42:47 UTC 2011

On Sun, Jan 2, 2011 at 10:54 AM, Gabriel Dos Reis <
gdr at integrable-solutions.net> wrote:

> On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll at googlemail.com> wrote:
>
> > This seems to be the current attitude in the Autoconf'ed world, where
> > uniform build environments are assumed and deviations from them are a
> > responsibility of the packager or builder.
>
> I don't know what you mean by that.  I don't recall that the GMP library
> is supposed to be linked against only in a uniform build environments, nor
> do I understand why that has to be assumed (in this specific case.)
>

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.

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.

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
 ;; machine architecture features:
 ;;   :x86      any Intel 386 or better, or compatibles like the AMD K6 or
K7
 ;;   :x86-64      any x86-64 CPU running in 64-bit mode
 ;;   :alpha;      DEC/Compaq Alpha CPU
 ;;   :sparc      any Sun UltraSPARC (possibly also non-Ultras -- currently
untested)
 ;;   :ppc      any PowerPC CPU
 ;;   :hppa      any PA-RISC CPU
 ;;   :mips      any MIPS CPU (in little-endian mode with :little-endian)

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

(:ANSI-CL :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS
 :SB-UNICODE :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :SPARC :UNIX
 :ELF :SUNOS :LINKAGE-TABLE :STACK-ALLOCATABLE-CLOSURES :OS-PROVIDES-DLOPEN
 :OS-PROVIDES-DLADDR :OS-PROVIDES-PUTWC :OS-PROVIDES-BLKSIZE-T
 :OS-PROVIDES-SUSECONDS-T)

On looking at other platforms, the number of combinations are always
limited. The implementation that excels at providing information is
Lispworks, which has
http://www.lispworks.com/documentation/lw60/LW/html/lw-600.htm#marker-1039551with
: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.

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.

OpenAxiom also takes two different approaches when it comes to GCL.
>From /open-axiom.trunk/config/open-axiom.m4
## For all values of L, except gcl, the assumption is that the Lisp
## image L is available in the build environment.  For  gcl,
## we make an exception: if no GCL image is available, or if
## the option --enable-gcl is specified then OpenAxiom builds its
## own version from the source tree.
So OpenAxiom contemplates and does build GCL from sources providing it with
the right compiler flags (the default ones plus optimizations) and *guessing
the "openaxiom_precision" from the C compiler itself*.

When preinstalled, *GCL itself will only supply OpenAxiom with the host_cpu
value given by Autoconf*, which is *what ECL is currently doing,* 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.

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.

Could ECL do better? But what?

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

if test "$axiom_lisp_flavor" = ecl; then
   openaxiom_host_lisp_precision=`ecl -eval '(print (* 8
(ffi:size-of-foreign-type :pointer-void)))' -eval '(quit)'`
fi

But will it match the logic after that that OpenAxiom uses to determine
compiler flags?

## Augment C and C++ compiler flags with ABI directives as appropriate
## before we proceed to infer other host datatype properties.
if test -n "$openaxiom_host_lisp_precision"; then
   case $GCC in
     yes)
       CPPFLAGS="$CPPFLAGS -m$openaxiom_host_lisp_precision"
       LDFLAGS="$LDFLAGS -m$openaxiom_host_lisp_precision"
       ;;
     no)
       # cross fingers and pray.
       ;;
   esac
fi

Well, this I can not assure.

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?

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/20110102/ca1fdc38/attachment.html>