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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Aaron M. Ucko-2
Source: efitools
Version: 1.4.2-2
Severity: important
Justification: fails to build from source

Thanks for fixing efitools's Build-Depends setting!  Automated builds
now get further, but still fail on i386, with

  In file included from simple_file.c:7:0:
  /usr/include/efi/efi.h:35:21: fatal error: efibind.h: No such file or irectory

(kfreebsd-amd64 builds also still fail, but with a different error
I'll report separately.)

The i386 version of this header turns out to be in
/usr/include/efi/ia32, not /usr/include/efi/i686.  I see no sign of a
config script that would report this location, so I suppose efitools
will need to hardcode the mapping.

I also noticed two further complications that will affect linking on
i386: the crt0 file is likewise named crt0-efi-ia32.o, and 32-bit
gnu-efi libraries are in /usr/lib32, which isn't in the default search
path.

Could you please take a look?

Thanks!

Reply | Threaded
Open this post in threaded view
|

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

pollux
On 04/26/2016 09:29 PM, Aaron M. Ucko wrote:

> Source: efitools
> Version: 1.4.2-2
> Severity: important
> Justification: fails to build from source
>
> Thanks for fixing efitools's Build-Depends setting!  Automated builds
> now get further, but still fail on i386, with
>
>   In file included from simple_file.c:7:0:
>   /usr/include/efi/efi.h:35:21: fatal error: efibind.h: No such file or irectory
>
> (kfreebsd-amd64 builds also still fail, but with a different error
> I'll report separately.)
>
> The i386 version of this header turns out to be in
> /usr/include/efi/ia32, not /usr/include/efi/i686.  I see no sign of a
> config script that would report this location, so I suppose efitools
> will need to hardcode the mapping.
>
> I also noticed two further complications that will affect linking on
> i386: the crt0 file is likewise named crt0-efi-ia32.o, and 32-bit
> gnu-efi libraries are in /usr/lib32, which isn't in the default search
> path.
>
> Could you please take a look?
>

Hi,

This specific bug is fixed in the upcoming upload (new upstream release
1.7.0)
However, a new problem appears:
ld: i386 architecture of input file `HelloWorld.o' is incompatible with
i386:x86-64 output

Indeed, on PC architectures, EFI executables are 64-bits EXE files.

I think the solution is to restrict the build to linux-amd64, and mark
the package as Multi-arch: foreign, however that would cover only the
embedded EFI files, not the tools to access UEFI variables.
That said, these tools use the efivars pseudo-filesystem and will only
work on Linux.

So, I think the next upload will restrict the package to linux-amd64 only.

Regards,
Pierre

Reply | Threaded
Open this post in threaded view
|

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

Steve McIntyre
On Fri, Apr 29, 2016 at 06:20:55PM +0200, pollux wrote:

>On 04/26/2016 09:29 PM, Aaron M. Ucko wrote:
>> Source: efitools
>> Version: 1.4.2-2
>> Severity: important
>> Justification: fails to build from source
>>
>> Thanks for fixing efitools's Build-Depends setting!  Automated builds
>> now get further, but still fail on i386, with
>>
>>   In file included from simple_file.c:7:0:
>>   /usr/include/efi/efi.h:35:21: fatal error: efibind.h: No such file or irectory
>>
>> (kfreebsd-amd64 builds also still fail, but with a different error
>> I'll report separately.)
>>
>> The i386 version of this header turns out to be in
>> /usr/include/efi/ia32, not /usr/include/efi/i686.  I see no sign of a
>> config script that would report this location, so I suppose efitools
>> will need to hardcode the mapping.
>>
>> I also noticed two further complications that will affect linking on
>> i386: the crt0 file is likewise named crt0-efi-ia32.o, and 32-bit
>> gnu-efi libraries are in /usr/lib32, which isn't in the default search
>> path.
>>
>> Could you please take a look?
>
>Hi,
>
>This specific bug is fixed in the upcoming upload (new upstream release
>1.7.0)
>However, a new problem appears:
>ld: i386 architecture of input file `HelloWorld.o' is incompatible with
>i386:x86-64 output
>
>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 think the solution is to restrict the build to linux-amd64, and mark
>the package as Multi-arch: foreign, however that would cover only the
>embedded EFI files, not the tools to access UEFI variables.
>That said, these tools use the efivars pseudo-filesystem and will only
>work on Linux.
>
>So, I think the next upload will restrict the package to linux-amd64 only.

Please don't do that. There are *4* Debian Linux architectures that
should be able to work here: amd64, i386, arm64 and armhf.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

Reply | Threaded
Open this post in threaded view
|

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

pollux
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)

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

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

>
>> I think the solution is to restrict the build to linux-amd64, and mark
>> the package as Multi-arch: foreign, however that would cover only the
>> embedded EFI files, not the tools to access UEFI variables.
>> That said, these tools use the efivars pseudo-filesystem and will only
>> work on Linux.
>>
>> So, I think the next upload will restrict the package to linux-amd64 only.
>
> 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.

Regards,
Pierre

Reply | Threaded
Open this post in threaded view
|

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

Steve McIntyre
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.                                [hidden email]
< 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 | Threaded
Open this post in threaded view
|

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

Luca Boccassi-3
On Fri, 29 Apr 2016 18:45:19 +0100 Steve McIntyre <[hidden email]>
wrote:
> 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?

Hi,

The latest upload from December builds fine on i386, amd64, armhf and
arm64, and as far as I can see it's building the EFI binaries with the
right LD scripts from gnu-efi, eg: elf_aarch64_efi.lds,
elf_ia32_efi.lds

So I think we can close this one too?

--
Kind regards,
Luca Boccassi

signature.asc (499 bytes) Download Attachment