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

Re: Bug#822725: Bug#822724: efitools: FTBFS on i386: efibind.h: No such file or directory



On Fri, Apr 29, 2016 at 07:31:11PM +0200, pollux wrote:
>On 04/29/2016 06:58 PM, Steve McIntyre wrote:
>> On Fri, Apr 29, 2016 at 06:20:55PM +0200, pollux wrote:
>>> Indeed, on PC architectures, EFI executables are 64-bits EXE files.
>> 
>> Ummm, what? 32-bit i386 (ia32) should be supported just fine. If it's
>> not working, that's just a bug.
>
>I'm talking about .efi files. If your firmware (BIOS) is 64-bits, then
>your executables can only use a 64-bits ABI for boot/runtime services.
>IA32 EFI firmwares are only used by some low-end platforms, or some
>embedded platforms (Intel Atom SoCs)

Right, but they're still valid platforms that exist in the wild. We
already support (for example) installation on Bay Trail based machines
that use ia32 UEFI.

>Not sure for ARM, but it may have the same problems.

UEFI is more common on arm64, but there are some 32-bit ARM machines
that will boot with UEFI, and probably more coming. We've just turned
on more UEFI support in the armmp kernels for this reason.

>See also http://mjg59.dreamwidth.org/26734.html for more problems with
>IA32 on x86

It's problematic, but it exists and is growing in usage - we can't
just ignore it.

>> Please don't do that. There are *4* Debian Linux architectures that
>> should be able to work here: amd64, i386, arm64 and armhf.
>
>I would like to, I'm just trying to find a solution that does not
>involved cross-compilation :/ The source package builds both native
>files, and .efi files.
>If you have any ideas they are welcome.

I don't see the problem - just build the appropriate binaries for each
of the architectures natively. Am I missing something?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
            handing rope-creating factories for users to hang multiple
            instances of themselves.


Reply to: