[Ecls-list] Help needed, really

[Juan Jose Garcia-Ripoll]

On Sat, Jan 1, 2011 at 10:01 PM, Gabriel Dos Reis <
gdr at integrable-solutions.net> wrote:

> > Extracting the information from there might be easier and more portable.
>
> Yes, that is what I suggested in private conversion.  In fact, all it takes
> is
> just link a dummy C file against the GMP library and look at the binary
> flavour of the program as indicated above.  I suspect that the `file'
> utility will handle most cases.


The hardest point of the conversation, and one that people do not seem to
get, is that I have no idea how to do this which is written in the paragraph
and in the discussion before. Really, it makes the discussion very hard that
people do not realize that I have no idea how to get binary information from
an executable, or gather the binary mode from GMP just by linking a custom
program -- to begin with, it would be utterly impossible to link against
this library before having guessed the appropriate linker/compiler flags!

Now, one might consider the possibilities that have been put forward here:

* Deduce the binary mode from C macros. That is possible but requires
keeping track of all possible operating systems that ECL might ship to, and
their respective compilers, and then reverse-engineer the names to
standardize them in some *features*. How to do that? I have never ever seen
a database of compiler macros and their associations to compilers which can
be reused.

* Using POSIX utilities such as "file". AFAIK, the output of the file
program is not standard (http://pubs.opengroup.org/onlinepubs/009695399/) and
at most one could either output the raw names or do some translation.

* Building some custom utility that inspects binary files.

* Reverse engineering the CFLAGS supplied to ECL.

* Autoconf triplets. ECL currently exports them as *features* and as the
output of other functions but they do not work. They are unreliable and OS
X, where OpenAxiom failed to build because of this, is an example.

* Using uname. But this provides the same information as Autoconf, needs
some parsing and I am not sure that it gives a different output for two
binary files built differently running on the same OS -- for instance 32-bit
and 64-bit applications --. Indeed I have seen 64-bit Solaris systems
reported as i686 by command line uname.

* Size of pointers. ECL provides this information via FFI. It is trivial to
obtain and would work for most platforms I know and use personally (Windows
right now, even with their ILP mode; OS X), but cannot guarantee that it
distinguishes among other build modes (for instance PPC multiple floating
point compilation modes)

* Adding the features manually for a couple of platforms and forget about
the rest. That would lead to a bunch of bug reports, if users do not get
disgusted before because ECL is broken.

...

Now let's put this in context. Should OpenAxiom or any other ECL user want
to link against a preinstalled GMP, or gnome library, would they demand that
the library supplies this information? How would they obtain that
information?

This is the question that should be asked and answered, because ECL itself
also suffers these problems with GMP itself -- being extremely platform
dependent and having its own wild choices of build modes, with arbitrary
naming, and no manual to decipher them, nor a way to gather the flags that
GMP was built with... ECL simply assumes that either the user knows the way
she built GMP and supplies the right CFLAGS, or lets ECL call GMP, configure
it and cut&paste their CFLAGS/LDFLAGS (which I never found to be full of
clutter).

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.

So I am really lost here. Please accept this as a sincere statementand not
some arbitrary resisitive attitude or an escape from a difficult problem as
it might have been hinted privately and here.

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