[Ecls-list] Help needed, really

[Gabriel Dos Reis]

On Sat, Jan 1, 2011 at 2:41 PM, DS <ecl at sol42.com> wrote:
>
> On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote:
>
>> What happens on macintel 64-bit with ECL is that ECL
>
>> puts out I686 instead there -- even when it is clearly a 64-bit binary
>
>> program.
>
>> ...
>
>> I explained that to Juanjo and suggested that ECL puts a more correct
>
>> token on *FEATURES*.
>
>> ...
>
>> and after reading indication
>
>> that ECL intentionally put misleading information regarding platforms on
>
>> *FEATURES*
>
>
>
> On Mac OS X 10.6.5 (64-bit kernel and everything):
>
> $ uname -m
>
> i386
>
>
>
> Looks like this is actually Mac OS X's fault.

On my system, ECL has the following as *FEATURES*

(:DARWIN :FORMATTER :LONG-LONG :UINT64-T :UINT32-T :UINT16-T
 :RELATIVE-PACKAGE-NAMES :LONG-FLOAT :DFFI :CLOS-STREAMS :CMU-FORMAT :ECL-PDE
 :DLOPEN :CLOS :BOEHM-GC :ANSI-CL :COMMON-LISP :IEEE-FLOATING-POINT
 :PREFIXED-API :FFI :I686 :COMMON :ECL)


even when uname -m reports the same value you indicated.
At any rate, I think `file' is far for reliable than `uname' because
file looks at the specific object file reflecting the binary
personaity, whereas `uname' gives something far for vague -- any
string would still be conforming.

> BTW,
>
> why
>
> is
>
> this
>
> mailing
>
> list
>
> software
>
> inserting
>
> new
>
> lines
>
> all
>
> over
>
> my
>
> messages?

I really do not know :-)

-- Gaby