[Ecls-list] Help needed, really

[Gabriel Dos Reis]

On Sat, Jan 1, 2011 at 2:23 PM, DS <ecl at sol42.com> wrote:
>
> On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote:
>
>> Anyway, I do no believe that the suggestion for ECL to make available
>
>> its binary flavor is equivalent to building and maintaining a database
>
>> of all imaginable ABIs and all combinations of processors.
>
>
>
> I believe Juanjo was referring to the second obvious way to figure out
> system info from C: conditional compilation.  In that case the C code
> would be sort of like

There usually are many ways to implement a specification.  That does not
necessarily mean we have to reject the specification just because, among
the many possible implementations, we have found one that we don't like :-)

> and you have to know the exact symbol used by every supported platform:
> some are lowercase, some are uppercase and have underscores, etc.  Same
> for system version and architecture.  This would be the database Juanjo
> does not want to build and maintain, and I find that understandable.

yes, but is a completely different issue and I don't see how that
would implement
the binary information in question.

The issue is to tell the binary flavour of the ecl program or libecl
library.  This is
the same kind of binary information that a dumb linker would use to reject
a binary file for not being compatible.  Lest this analogy be misconstrued, I am
emphasizing that I am not suggesting that ECL writes its own linker.
I'm just saying
that the binary information is one that comes from the RESULTING
program or library,
not the size of the C integer types used.

>
> BTW this is the only way to tell one C compiler from another from
> 'inside' C that I know of.

yes, but it is not reliable information and I'm not sure how
that is necessary and why it implements the binary flavour of a
program.

> The first obvious way (for me at least) would be the uname() libc call,
> but it is more limited and as far as I know is not present on some
> platforms, so it would require an autoconf test.

It is true that uname while being a POSIX function may not be present
on all system, and even it is it may not give what we are looking for.

Another way of thinking about this is that you are given binary objects
to link together to construct a program.  You do not have access to the
original program.  But, you can tell the binary flavour by just looking at
the header of each binary object file -- that is in essence what
`file' utility does, and that is a preliminary step of linkers.  DISCLAIMER:
I am not suggesting that ECL reimplements `file' or a linker.
On POSIX systems, ECL can just issue `file
test-program-linked-against-required-c-lib'
and use the output to determine the binary flavour.  On non-posix
systems (not many,
among the platforms where this actually matters.), it can have its own
custom program
to look at the header of the test program.  Certainly using Autoconf's
triplet in an improved
way  may remove the need to have to write custom header reading program.

> Figuring out the ILP32/LP64/whatever bit is a matter of comparing
> sizeof()'s.  It is also easy to figure out endianness.  This is very
> simple and portable C code.

Autoconf now has standard macros to test endianness at configuration time.
At this point, I'm not asking for ILP32/LP64/LLP64 -- though I recognize that
other ECL users want find it useful to have.

> OTOH configure scripts usually do some or all of these tests.  GMP is
> extremely platform-dependant and surely knows about all this.

Yes, definitely.

> 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.  Taking the Ruby interpreter I gave earlier,
I have

ring:~ gdr$ file `which ruby`
/usr/bin/ruby: Mach-O universal binary with 3 architectures
/usr/bin/ruby (for architecture x86_64):        Mach-O 64-bit executable x86_64
/usr/bin/ruby (for architecture i386):  Mach-O executable i386
/usr/bin/ruby (for architecture ppc7400):       Mach-O executable ppc


The glaring case where `file' won't work is if compling on Windows
using MS toolchain.
In which case, we know we are dealing with PE/COFF binary file and we know how
to get the information.  For the rest, old UNIX `file' utility does the work.

-- Gaby