* Always use objcopy -O (--target doesn't make sense)
and isn't available on freebsd
* No efi-bsdrv target (but has efi-app)(bug in binutils??)
* Sync linker scripts (all features are supported)
* Use clang as HOSTCC (there is no default gcc)
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
* Doesn't seem to like nocombreloc
* i686 doesn't have the efi-app-ia32 target (bug in binutils??)
* Set float manually on ARM32 due to generic toolchain
* Ensure _DYNAMIC symbol exists
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
* Means we don't have to switch the implementation of char to unsigned char
* Matches the underlying type of char8_t from C++20
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
musl-libc doesn't like fshort-wchar so remove wchar_t usage
Use uint16_t as char16_t can be up to 32bits
Fixesncroxon/gnu-efi#16
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
This is similar to using automake's silent rules and, just as with automake,
can be disabled by invoking 'make V=1'.
Signed-off-by: Pete Batard <pete@akeo.ie>
The EFI subsystem and application entrypoint were not being set for MinGW builds
and we don't need to go through objcopy either, so fix that.
Also make sure that the link options can be understood by the compiler, which
is what we use for linking, and remove the extra GNU_EFI_USE_MS_ABI, that was
already automatically added.
Signed-off-by: Pete Batard <pete@akeo.ie>
To builds the apps with MinGW, the CRT0 library must be ignored because
it is ELF specific and we don't need to go through ELF relocations.
We also apply the GNU_EFI_USE_MS_ABI (since we have it), remove the -z
flags, that are invalid in MinGW, and clean up the apps Makefile.
Note that setjump and debughook are excluded from MinGW builds as they
use constructs that are not available there.
Signed-off-by: Pete Batard <pete@akeo.ie>
For downright incomprehensible reasons the Ubuntu/MinGW folks have decided that MinGW on
Ubuntu should no longer report the compiler's version as '<major>.<minor>', but instead as
'<major>-win32', which of course breaks any script that attempts to read version numbers.
This results in MinGW compilation of gnu-efi on Ubuntu producing the error:
/bin/sh: 1: [: Illegal number: 10-win32
Fix this by replacing any '-win32' in the -dumpversion report with '.0' so that we get an
approximate version number back again.
Signed-off-by: Pete Batard <pete@akeo.ie>
The UEFI shorthands, as used in /efi/boot/boot###.efi, can now be used to specify the arch.
This basically adds 'x64' and 'mips64' as valid arch specifiers.
Signed-off-by: Pete Batard <pete@akeo.ie>
No point having PT_GNU_RELRO as ELF data won't exist when merging into PE32+ file
Unbreaks lld usage which complains about linker script
Fixesncroxon/gnu-efi#4
Binutils 2.41 now supports efi-app-loongarch64, so to use this we must add a
dummy reloc section and remove the PE header definition from crt0 as this will
conflict with the version added by objcopy
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
Also add EXEC_PREFIX and INCLUDEDIR variables
This was requested by fwupd-efi, to be able
to retrieve the version number of gnu-efi
so we can detect features
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
This makes us use CFLAGS when trying to find libgcc, so we don't get the
one with the wrong endian or float ABI.
Signed-off-by: Peter Jones <pjones@redhat.com>
This makes the normal DESTDIR= variable work on the command line, and
makes relative paths always relative to the top-level directory.
Signed-off-by: Peter Jones <pjones@redhat.com>
Date: Tue Feb 7 21:48:27 2023 +0000
ARM32/x86_64 lds: Force data segment align to 4KiB
Some newer versions of binutils can set invalid COMMONPAGESIZE
and MAXPAGESIZE values on these architectures
git fetch git.code.sf.net/u/gmbr3/gnu-efi arm-pagesize
git merge 89d55b364d
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
We need the x86_64 and i686 builds of .a's to be the same, and that
means we need to not have timestamps. Also force the timestamps on disk
just in case that doesn't work, because RHEL's ar /silently ignores -D/.
v2: use "ar rvD" not "ar rv -D".
It's a wonder anybody ever gets these command line options right, if
"ar rv -D libfoo.a foo.o" doesn't use deterministic mode (or
complain), but "ar rvD libfoo.a foo.o" does.
v3: Add a bunch of junk to try to set timestamps to 0 manually
For some reason I'm still getting timestamps in the .a even though ar seems to
be invoked correctly. When I do "mock -r rhel-7-build --shell" and run make
manually, they're fine. Very strange.
v4: go back to v2, the problem isn't in the make process.
"ar rDv" works just fine, but /usr/lib/rpm/redhat/brp-strip-static-archive is
calling "%{__strip} -g $for_each.a", and it's rewriting our binary from
ts/uid/gid of 0/0/0 to $epoch/$UID/$GID. Awesomely /usr/bin/strip it seems to
have 3 modes of operation:
-U: the default, which adds $epoch/$UID/$GID to your binary archive
instead of just removing stuff. Clearly the Principle of Least
Surprise is strong here.
-p: preserve the timestamp from the original .a, but add UID and GID,
because this is 1980 and people use ar(1) for archiving stuff they
might want that out of.
-D: Condescend at you in a command line error and explain that -D both
is and is not a valid option:
/usr/bin/strip: invalid option -- 'D'
Usage: /usr/bin/strip <option(s)> in-file(s)
Removes symbols and sections from files
The options are:
...
-D --enable-deterministic-archives
Produce deterministic output when stripping archives
So I agree that it's invalid, but I think we may be pronouncing that
second vowel differently. They say in-VAL-id, I say IN-vuh-lid.
Nobody should ever have to run "strace -ttt -v -f -o make.strace make all",
just to discover the problem isn't even in there.
Related: rhbz#1310782
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Previous work was apparently done with arm-linux-gnueabi-gcc as a
cross-builder, but our armv7 builders have native gcc with the target as
armv7hl-linux-gnueabi, so we need to munge the arch there to get our arm
path.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
If gnu-efi is compiled with "-march=native" on a host that supports AVX, both
gcc and clang will use AVX instructions freely which is currently not supported
and will result in a non-functional gnu-efi build (e.g. black screen, hangs).
For now, disable AVX on IA32 and x86_64 by checking first if the compiler does
actually support the appropriate flag (-mno-avx) and use it if possible.
Credit for the compiler command line to check if a flag is supported goes to
Gentoo's awesome flag-o-matic eclass, where it is taken from. Thanks.
Signed-off-by: Matthias Dahl <matthias.dahl@binary-island.eu>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Tested:
make all apps + tests apps/ on x86_64
make CC=clang all apps + tests apps/ on x86_64
Signed-off-by: David Decotigny <ddecotig@gmail.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
GNU ar currently produces the following string of warnings:
Warning: Archive 'libefi.a' seems to have been created in
deterministic mode.
'<file>.o' will always be updated. Please consider passing
the U flag to ar to avoid the problem. This patch fixes the issue.
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <noxorc@users.sf.net>
point and as far as I can tell it agrees with the UEFI spec.
The attached patch removes -mno-mmx and -mno-sse for x86_64 and adds
a new Print target, "%f", to print float and double types.
It seems to compile for ia32, although I'm not sure why - shouldn't
it be throwing errors because the new function FloatToStr() in print.c
accepts a float, yet I left -no-sse for ARCH=ia32? A better solution
might be to add -msoft-float for targets where the floating point
calling convention doesn't match the UEFI spec. As I'm not familiar
with UEFI on ia32, I didn't make any changes to it.
Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
result, which breaks gnu-efi compilation due to -Werror:
gnu-efi/lib/boxdraw.c:1:0: error: -fpic ignored for target
(all code is position independent) [-Werror]
This patch ensures that -fpic is disabled when MinGW is used.
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
