Hello,
I wanted to ask if there's a reason efi/wrapper.{h,c} use __uint*_t
instead of including stdint.h and using the therein defined uint*_t
types? This breaks compilation of the efi blobs on systems with the musl
libc since that doesn't define __uint*_t types.
--
Simon Thelen
On Sat, Dec 2, 2017 at 1:32 PM, Simon Thelen via Syslinux <syslinux at zytor.com> wrote:> Hello, > > I wanted to ask if there's a reason efi/wrapper.{h,c} use __uint*_t > instead of including stdint.h and using the therein defined uint*_t > types? This breaks compilation of the efi blobs on systems with the musl > libc since that doesn't define __uint*_t types.Good question. Those two and some XFS stuff are the only instances. I thought the __uint{8,16,32,64}_t were more glibc specific. Matt/HPA,any thoughts? -- -Gene
> Hello, > > I wanted to ask if there's a reason efi/wrapper.{h,c} use __uint*_t > instead of including stdint.h and using the therein defined uint*_t > types? This breaks compilation of the efi blobs on systems with the musl > libc since that doesn't define __uint*_t types. > > -- > Simon ThelenFWIW... As a simple quick basic test, I took the efi32 binaries (syslinux.efi and ldlinux.e32, version 6.04-pre1) from alpinelinux (which uses musl) and put them in a FAT 1440KiB floppy image using the default UEFI path. While booting a VM with such floppy image in EFI mode, I arrive to the syslinux boot prompt. I have not attempted to execute any kernel, nor any c32 module, but the most basic functionality (i.e. booting to the boot prompt) worked, so I assume that the binaries were successfully built (i.e. if there was some building issue, it was not completely catastrophic). Regards, Ady.
On 17-12-03 at 17:17, Ady Ady via Syslinux wrote:> FWIW... > > As a simple quick basic test, I took the efi32 binaries (syslinux.efi > and ldlinux.e32, version 6.04-pre1) from alpinelinux (which uses musl) > and put them in a FAT 1440KiB floppy image using the default UEFI path. > > While booting a VM with such floppy image in EFI mode, I arrive to the > syslinux boot prompt. > > I have not attempted to execute any kernel, nor any c32 module, but the > most basic functionality (i.e. booting to the boot prompt) worked, so I > assume that the binaries were successfully built (i.e. if there was > some building issue, it was not completely catastrophic).I actually checked this and Alpine linux uses the pre-built binary blobs that lie in the syslinux tarfile [1]. It only builds the installer target and then installs the files without building the subdirs target thereby bypassing the build failure in the efi subdirectory. [1]: https://git.alpinelinux.org/cgit/aports/tree/main/syslinux/APKBUILD -- Simon Thelen