Drop the needless efi-cc and efi-ld parameters

[superm1]

Fixes: #6

[hughsie]

I get this on Fedora:

FAILED: efi/fwup.so 
/usr/bin/ld.bfd -o efi/fwup.so -T /home/hughsie/Code/fwupd-efi/efi/lds/elf_x86_64_efi.lds -shared -Bsymbolic -nostdlib -znocombreloc -L /usr/lib -L /usr/lib /usr/lib/crt0-efi-x86_64.o efi/fwupdate.o efi/fwup-debug.o efi/fwup-efi.o efi/fwup-common.o efi/fwup-sbat.o -lefi -lgnuefi /usr/lib/gcc/x86_64-redhat-linux/12/libgcc.a
/usr/bin/ld.bfd: skipping incompatible /usr/lib/libefi.a when searching for -lefi
/usr/bin/ld.bfd: skipping incompatible /usr/lib/libefi.a when searching for -lefi
/usr/bin/ld.bfd: cannot find -lefi: file in wrong format
/usr/bin/ld.bfd: skipping incompatible /usr/lib/libgnuefi.a when searching for -lgnuefi
/usr/bin/ld.bfd: skipping incompatible /usr/lib/libgnuefi.a when searching for -lgnuefi
/usr/bin/ld.bfd: cannot find -lgnuefi: file in wrong format

[superm1]

Hmm I guess on Fedora it's using a different linker by default? If you switch to ld.gold does it work?

[superm1]

I think the problem is actually the RPM packaging doing something super weird. I think that /usr/lib/gnuefi.a doesn't match the right architecture. We can probably work around it, but can you check that?

[hughsie]

There is certainly some symlinks, might that confuse things?

$ ls /usr/lib/gnuefi/* -l
lrwxrwxrwx. 1 root root   11 Jul 21 08:53 /usr/lib/gnuefi/crt0-efi-ia32.o -> ia32/crt0.o
lrwxrwxrwx. 1 root root   12 Jul 21 08:53 /usr/lib/gnuefi/elf_ia32_efi.lds -> ia32/efi.lds
lrwxrwxrwx. 1 root root   13 Jul 21 08:53 /usr/lib/gnuefi/libefi.a -> ia32/libefi.a
lrwxrwxrwx. 1 root root   16 Jul 21 08:53 /usr/lib/gnuefi/libgnuefi.a -> ia32/libgnuefi.a

/usr/lib/gnuefi/ia32:
total 124
-rw-r--r--. 1 root root    876 Jul 21 08:53 crt0.o
-rw-r--r--. 1 root root   2080 Jul 21 08:53 efi.lds
-rw-r--r--. 1 root root 114152 Jul 21 08:53 libefi.a
-rw-r--r--. 1 root root   1186 Jul 21 08:53 libgnuefi.a

/usr/lib/gnuefi/x64:
total 144
-rw-r--r--. 1 root root   1272 Jul 21 08:53 crt0.o
-rw-r--r--. 1 root root   1970 Jul 21 08:53 efi.lds
-rw-r--r--. 1 root root 132920 Jul 21 08:53 libefi.a
-rw-r--r--. 1 root root   1498 Jul 21 08:53 libgnuefi.a

[superm1]

/usr/lib/gnuefi/libgnuefi.a -> ia32/libgnuefi.a

That's the problem. It should be a symlink to the x64 version. I think we can do a workaround in fwupd-efi, but this should be fixed in the RPM.

[superm1]

Have a try with what I just pushed

[hughsie]

Have a try with what I just pushed

Works.

[hughsie]

I guess my only concern is:

Message: efi-libdir: "/usr/lib/../lib64"
Message: efi-ldsdir: "/home/hughsie/Code/fwupd-efi/efi/lds"
Message: efi-crtdir: "/usr/lib/../lib64/gnuefi"

which I think is fine?

[rossburton]

I can test this on an aarcch64 machine on Monday if nobody else has access.

[superm1]

I can test this on an aarcch64 machine on Monday if nobody else has access.

Yes, please!

[superm1]

I guess my only concern is:

Message: efi-libdir: "/usr/lib/../lib64"
Message: efi-ldsdir: "/home/hughsie/Code/fwupd-efi/efi/lds"
Message: efi-crtdir: "/usr/lib/../lib64/gnuefi"

which I think is fine?

I thought it should be fine too.