..to reflect the GRUB build reality in them.
Additionally, fix text formatting a bit.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Commit d5a32255d (misc: Make grub_strtol() "end" pointers have safer
const qualifiers) introduced "restrict" keyword into some functions
definitions. This keyword was introduced in C99 standard. However, some
compilers by default may use C89 or something different. This behavior
leads to the breakage during builds when c89 or gnu89 is in force. So,
let's set gnu99 C language standard for all compilers by default. This
way a bit random build issue will be fixed and the GRUB source will be
build consistently regardless of type and version of the compiler.
It was decided to use gnu99 C language standard because it fixes the
issue mentioned above and also provides some useful extensions which are
used here and there in the GRUB source. Potentially we can use gnu11
too. However, this may reduce pool of older compilers which can be used
to build the GRUB. So, let's live with gnu99 until we discover that we
strongly require a feature from newer C standard.
The user is still able to override C language standard using relevant
*_CFLAGS variables.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The memory management system supports a debug mode that can be enabled
at build time by passing "--enable-mm-debug" to the configure script.
Passing the option will cause us define MM_DEBUG as expected, but in
fact the reverse option "--disable-mm-debug" will do the exact same
thing and also set up the define. This currently causes the build of
"lib/gnulib/base64.c" to fail as it tries to use `grub_debug_malloc()`
and `grub_debug_free()` even though both symbols aren't defined.
Seemingly, `AC_ARG_ENABLE()` will always execute the third argument if
either the positive or negative option was passed. Let's thus fix the
issue by moving the call to`AC_DEFINE()` into an explicit `if test
$xenable_mm_debug` block, similar to how other defines work.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
While GRUB has no platform support for SuperH (sh4) yet, this change
adds the target-specific handling of soft-floats such that the GRUB
utilities can be built on this target.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
PIE should be disabled in assembly sources as well, or else GRUB will
fail to boot.
Bug: https://bugs.gentoo.org/667852
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
On a 32-bit SPARC userland, configure fails to compile assembly and the
build fails:
checking for options to compile assembly... configure: error: could not compile assembly
config.log shows:
asm-tests/sparc64.S: Assembler messages:
asm-tests/sparc64.S:5: Error: Architecture mismatch on "lduw [%o4+4],%o4".
asm-tests/sparc64.S:5: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is sparclite.)
asm-tests/sparc64.S:7: Error: Architecture mismatch on "stw %o5,[%o3]".
asm-tests/sparc64.S:7: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is sparclite.)
asm-tests/sparc64.S:8: Error: Architecture mismatch on "bne,pt %icc,1b ,pt %icc,1b".
asm-tests/sparc64.S:8: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is sparclite.)
Simply moving these blocks earlier in configure.ac is sufficient to
ensure that the tests are executed with the appropriate flags
(specifically -m64 in this case).
Bug: https://bugs.gentoo.org/667850
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
This is needed for the zstd module build for riscv64-emu.
Signed-off-by: Andreas Schwab <schwab@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
MinGW for i386-pc without this option generates a .rdata$zzz symbol that is
page-aligned and hence lzma_decompress no longer fits in its allocated space.
Additionally, MinGW with -fno-ident also saves a bit of space in modules. In
case of other compilers we already strip the relevant sections, so, this
option has no effect.
More info can be found at https://github.com/msys2/MINGW-packages/issues/21
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When building for arm, we already disable movw/movt relocations for clang,
since they are incompatible with PE.
When building with bare metal GCC toolchains (like the one used in the
travis ci scripts), we end up with these relocations again. So add an
additional test for the '-mword-relocations' flag used by GCC.
Reported-by: Alexander Graf <agraf@csgraf.de>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When assembling module wirh clang -Qn ends up on command line but later ignored
To avoid it breaking the compile, add -Qunused-arguments.
Signed-off-by: Vladimir Serbinenko <phcoder@google.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
With clang nostdinc behaviour is influenced by nostdlib. Since we
always add nostdlib, add it in test as well
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Vladimir Serbinenko <phcoder@google.com>
Upgrade Gnulib files to 20190105.
It's much easier to maintain GRUB's use of portability support files
from Gnulib when the process is automatic and driven by a single
configuration file, rather than by maintainers occasionally running
gnulib-tool and committing the result. Removing these
automatically-copied files from revision control also removes the
temptation to hack the output in ways that are difficult for future
maintainers to follow. Gnulib includes a "bootstrap" program which is
designed for this.
The canonical way to bootstrap GRUB from revision control is now
"./bootstrap", but "./autogen.sh" is still useful if you just want to
generate the GRUB-specific parts of the build system.
GRUB now requires Autoconf >= 2.63 and Automake >= 1.11, in line with
Gnulib.
Gnulib source code is now placed in grub-core/lib/gnulib/ (which should
not be edited directly), and GRUB's patches are in
grub-core/lib/gnulib-patches/. I've added a few notes to the developer
manual on how to maintain this.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
