This patch adds support for RISC-V to the grub build system. With this
patch, I can successfully build grub on RISC-V as a UEFI application.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Support platform i386/xen_pvh in configure.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
gentpl.py is python2/3-agnostic, but there's no way to cause it
to be run with any interpreter other than 'python', it's just
hard-coded into Makefile.common that way. Adjust that to use
AM_PATH_PYTHON (provided by automake) to find an interpreter
and run gentpl.py with that instead. This makes grub buildable
when `python` does not exist (but rather `python3` or `python2`
or `python2.7`, etc.) Minimum version is set to 2.6 as this is
the first version with `__future__.print_function` available.
Note, AM_PATH_PYTHON respects the PYTHON environment variable
and will treat its value as the *only* candidate for a valid
interpreter if it is set - when PYTHON is set, AM_PATH_PYTHON
will not try to find any alternative interpreter, it will only
check whether the interpreter set as the value of PYTHON meets
the requirements and use it if so or fail if not. This means
that when using grub's `autogen.sh`, as it too uses the value
of the PYTHON environment variable (and if it is not set, just
sets it to 'python') you cannot rely on AM_PATH_PYTHON
interpreter discovery. If your desired Python interpreter is
not just 'python', you must set the PYTHON environment variable,
e.g. 'PYTHON=/usr/local/bin/python3 ./autogen.sh'. The specified
interpreter will then be used both by autogen.sh itself and by
the autotools-driven build scripts.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
pkg-config is apparently preferred over freetype-config these days (see
the BUGS section of freetype-config(1)). pkg-config support was added
to FreeType in version 2.1.5, which was released in 2003, so it should
comfortably be available everywhere by now.
We no longer need to explicitly substitute FREETYPE_CFLAGS and
FREETYPE_LIBS, since PKG_CHECK_MODULES does that automatically.
Fixes Debian bug #887721.
Reported-by: Hugh McMaster <hugh.mcmaster@outlook.com>
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Using FREETYPE_CFLAGS and FREETYPE_LIBS is more in line with the naming
scheme used by pkg-config macros.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We don't use lgcc_s but missing lgcc_s or another library cause test to fail.
So use -nostdlib.
We need to use -Werror to avoid warning-generated case to be accepted.
Clang uses -nopie rather than -no-pie. Check both and use whichever one works.
Additionally android clang passes -pie to the linker even though it doesn't
define __PIE__. So if compilation without no-pie logic fails add -nopie/-no-pie
even if __PIE__ is not defined.
clang 3.8 and later doesn't support -mllvm -use-arm-movt=0
whereas older clang doesn't know -mno-movt. So use
-mno-movt whenever possible and fallback to mllvm variant.
glibc 2.25 still includes sys/sysmacros.h in sys/types.h but also emits
deprecation warning. So test for sys/types.h succeeds in configure but later
compilation fails because we use -Werror by default.
While this is fixed in current autoconf GIT, we really cannot force everyone
to use bleeding edge (that is not even released right now). So run test under
-Werror as well to force proper detection.
This should have no impact on autoconf 2.70+ as AC_HEADER_MAJOR in this version
simply checks for header existence.
Reported and tested by Khem Raj <raj.khem@gmail.com>
When Grub is compile with gcc 6.1 that have --enable-defult-pie set.
It fail with.
-ffreestanding -m32 -Wl,-melf_i386 -Wl,--build-id=none -nostdlib -Wl,-N -Wl,-r,-d -
o trig.module trig_module-trigtables.o
grep 'MARKER' gcry_whirlpool.marker.new > gcry_whirlpool.marker; rm -f
gcry_whirlpool.marker.new
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: -r and -
shared may not be used together
collect2: error: ld returned 1 exit status
Makefile:26993: recipe for target 'trig.module' failed
Check that compiler supports -no-pie and add it to linker flags.
Depending on the OS/libc, device macros are defined in different
headers. This change ensures we include the right one.
sys/types.h - BSD
sys/mkdev.h - Sun
sys/sysmacros.h - glibc (Linux)
glibc currently pulls sys/sysmacros.h into sys/types.h, but this may
change in a future release.
https://sourceware.org/ml/libc-alpha/2015-11/msg00253.html
OpenBSD 5.9 apparently defaults to -fpie. We use -fno-PIE when appropriate
already, but that is not enough - it does not turn off -fpie.
Actually check for -fPIE is not precise enough. __PIE__ is set for both
-fpie and -fPIE but with different values. As far as I can tell, both
options were introduced at the same time, so both should always be supported.
This fixes compilation on OpenBSD 5.9 which otherwise created insanely big
lzma_decompress.img.
Reported, suggested and tested by: Jiri B <jirib@devio.us>
efiemu is supposed to be disabled when compiling through exe format.
Unfortunately format was determined only after efiemu check. Reorder to fix the
problem
This argument disables generation of calls to __chkstk_ms. Those calls are
useless on GRUB as function is dummy. Yet they increase module size and
use limited-range relocations which may not work under some memory layouts.
We currently don't use such layouts on concerned platforms but lt's correct
this.
Macports add extra information after version itself:
$flex --version
flex 2.5.35 Apple(flex-31)
We require at least felx 2.5.35 so do not need to care about prehistoric
"flex version n.n.n"; just use second field always.
Reported by Peter Cheung <mcheung63@hotmail.com>
GRUB code expects O32 or N32. N32 is less tested than O32, so we prefer to
compile with O32. Some systems (e.g. GNU Guix) default to using newer
n64 or n32 ABI. Try to find suitable options to force o32.
For GCC this is simply -mabi=32. While clang supports this option as well,
o32 ABI is valid for MIPS target and n32/64 ABI are valid for MIPS64 target
only, so use "-target mips/mipsel -mabi=32".
Reported-By: Mark H Weaver <mhw@netris.org>
Also-By: Mark H Weaver <mhw@netris.org>
Fix compilation with gcc 5.1 (avoid internal compiler error), by
replacing explicit -march +nofp+nosimd options with -mgeneral-regs-only.
This also enables the removal of some further conditional build flag
setting.
libgcc for boot environment isn't always present and compatible.
libgcc is often absent if endianness or bit-size at boot is different
from running OS.
libgcc may use optimised opcodes that aren't available on boot time.
So instead of relying on libgcc shipped with the compiler, supply
the functions in GRUB directly.
Tests are present to ensure that those replacement functions behave the
way compiler expects them to.
Add -msoft-float alongside clang arguments to specify ABI.
Specify ABI in asm files explicitly.
This trigers asm warning due to gcc failing to propagate -msoft-float
but it's tolerable.
