[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: -= PROPOSAL =- Release sarge with amd64



tb@becket.net (Thomas Bushnell, BSG) writes:

> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
>
>
>> > That's not an adequate error--but it should be simple to write a
>> > trivial "loader" which provides a more useful error.
>> >
>> > Thomas
>> 
>> You get the same error as with any binary with unfullfillable
>> libraries.
>
> No, it's what you get when the loader can't be found (and it's a
> horrible error: it should print the name of the missing loader, not
> the executable).
>
> But if you want to avoid LSB complaince, then you have to pretend that
> amd64 is a totally different architecture.  That requires *not* giving
> a normal 386 no-such-loader error, but instead something associated
> with "this binary is for a different architecture than the one you are
> running".  When I run a 386 binary on my ppc Debian system, I get
> "cannot execute binary file" which is a whole lot more useful.  If I
> use the file command I get something helpfully different, because it
> says it's an executable for a totally different processor.

That would mean patching the kernel and porting the binfmt-elf ia32 to
be a binfmt misc extention and only loading that if ia32-libs is
installed.

No way.

> If you want to pretend that amd64 is not 386 and is a different
> architecture, then you can (in my opinion), avoid the LSB issue--but
> only if you do a sufficiently good job of making the "different
> architecture" work the way it should.

No. You can easily say "we compliy with the amd64 LSB" and still
support other stuff outside of it (like being compatible with the
ia32 LSB without full compliance). The LSB doesn't require support to
end at the LSB.

It wouldn't be in our users best intrest to do that anyway.

MfG
        Goswin



Reply to: