Revert setjmp/longjmp ABI break in #77

[lzcunt]

aa27c28 introduced an ABI break in a minor version which broke syslinux. syslinux externs the setjmp/longjmp implementation of GNU-EFI, therefore depends on the symbol name.

Let's alias base_setjmp and base_longjmp to setjmp and longjmp respectively so syslinux builds again.

[gmbr3]

a) syslinux is abandoned
b) this shouldn't be required and this isn't a complete (undo-)changeset compared to the changes made previously

Copies of syslinux failing to compile would be useful since I don't get how this fits

[lzcunt]

a) syslinux is abandoned

Yet it is still used. Many tools depend on it. Quite a lot of distros still use syslinux for their ISOs for legacy BIOS booting. GRUB is often seen as too heavyweight for ISOs, and systemd-boot is a good alternative for UEFI systems. e.g. in NixOS we build ISOs with syslinux for BIOS and systemd-boot for UEFI but then default to GRUB for BIOS and systemd-boot for UEFI systems. AFAIK this is pretty common across distributions.

b) this shouldn't be required and this isn't a complete (undo-)changeset compared to the changes made previously

I called it "revert" because the ABI break is being reverted, not because the commit is being reverted.

Copies of syslinux failing to compile would be useful since I don't get how this fits

NixOS/nixpkgs#467914

[lzcunt]

Marked as a draft as I haven't built syslinux with this patch yet.

[gmbr3]

syslinux is abusing header files

It is using the system provided setjmp.h and then linking with gnu-efi's setjmp - gnu-efi's setjmp was never compatible with ISO C setjmp pre-4.0.2 (hence the change)

[lzcunt]

syslinux is abusing header files

no. syslinux has it's own setjmp header and implementation which for some reason is not being linked? so it is a syslinux bug, that's correct but it's not using system header files

It is using the system provided setjmp.h and then linking with gnu-efi's setjmp - gnu-efi's setjmp was never compatible with ISO C setjmp pre-4.0.2 (hence the change)

well it is compatible now (post 4.0.3) and changing the symbol name breaks syslinux regardless of
if the previous implementation was meant to be compatible. syslinux may be abandonware but it's not hard to not break it in a minor release. many distros still depend on syslinux and still use gnu-efi 3 and when they eventually upgrade this will cause issues. according to repology it's basically only Alpine and NixOS that's on gnu-efi 4. we can always roll back to gnu-efi 3 (which we do for a couple packages that don't support gnu-efi 4 yet) but I'd prefer to drop gnu-efi 3 eventually.

it may be a syslinux bug but there is no way to get a patch upstreamed there at this point.