summaryrefslogtreecommitdiffstats
path: root/src/Makefile.housekeeping
Commit message (Collapse)AuthorAgeFilesLines
* [build] Do not use "git log" to construct build timestampMichael Brown2026-01-221-2/+0Star
| | | | | | | | | | | | | | Using "git log" to automatically construct the build timestamp is of minimal value. Reproducible builds should be using SOURCE_DATE_EPOCH anyway, and for ad hoc builds it is arguable that the time at which the build was performed is more relevant than the commit timestamp. (For example, the user may be trying to deliberately use an older version of iPXE in order to track down a regression via bisection.) Remove the use of "git log", and thereby remove any requirement for the git tools to be available at the point of building iPXE. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow for per-architecture sysrootsMichael Brown2026-01-211-0/+5
| | | | | | | | | | | | | | | | As done for CROSS_COMPILE in commit 8fc11d8 ("[build] Allow for per-architecture cross-compilation prefixes"), allow a default sysroot for each architecture to be specified via the SYSROOT_<arch> variables. These may then be provided as environment variables, e.g. using export SYSROOT_riscv32=/usr/riscv32-linux-gnu/sys-root This is particularly useful for architectures such as RISC-V where the 64-bit compiler is also used to build 32-bit binaries, since in those cases the compiler will default to using the 64-bit sysroot. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fail Secure Boot builds unless all files are permittedMichael Brown2026-01-141-5/+3Star
| | | | | | | | | | | | | | | Add the Secure Boot permissibility check as a dependency for targets built with the Secure Boot flag enabled. Attempting to build e.g. make bin-x86_64-efi-sb/snponly.efi will now fail unless all files used in the final binary are marked as being permitted for Secure Boot. This does not affect the standard build targets (without the "-sb" suffix on the build directory). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Check for standalone FILE_LICENCE() and FILE_SECBOOT() declarationsMichael Brown2026-01-141-3/+12
| | | | | | | | | Tighten up the regular expression used to check for FILE_LICENCE() and FILE_SECBOOT() declarations: ensure that they appear at the start of a line (with optional whitespace) and include the expected opening parenthesis. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Mark existing files as explicitly forbidden for Secure BootMichael Brown2026-01-131-5/+0Star
| | | | | | | | | | | | | | | The third-party 802.11 stack and NFS protocol code are known to include multiple potential vulnerabilities and are explicitly forbidden from being included in Secure Boot signed builds. This is currently handled at the per-directory level by defining a list of source directories (SRCDIRS_INSEC) that are to be excluded from Secure Boot builds. Annotate all files in these directories with FILE_SECBOOT() to convey this information to the new per-file Secure Boot permissibility check, and remove the old separation between SRCDIRS and SRCDIRS_INSEC. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Define a mechanism for marking Secure Boot permissibilityMichael Brown2026-01-131-8/+33
| | | | | | | | | | | | Not all files within the iPXE codebase are allowed to be included in UEFI Secure Boot signed builds. Following the pattern used by the existing FILE_LICENCE() macro and licensing check: define a FILE_SECBOOT() macro that can be used to declare a file as being permitted (or forbidden) in a UEFI Secure Boot signed build, and a corresponding build target to perform the check. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Disable use of common symbolsMichael Brown2025-06-241-10/+7Star
| | | | | | | | | We no longer have any requirement for common symbols. Disable common symbols via the -fno-common compiler option, and simplify the test for support of -fdata-sections (which can return a false negative when common symbols are enabled). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow for 32-bit and 64-bit versions of util/zbinMichael Brown2025-05-061-3/+8
| | | | | | | | | | Parsing ELF data is simpler if we don't have to build a single binary to handle both 32-bit and 64-bit ELF formats. Allow for separate 32-bit and 64-bit binaries built from util/zbin.c (as is already done for util/elf2efi.c). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Disable gcc unterminated-string-initializer warningsMichael Brown2025-04-271-0/+9
| | | | | | | | | | GCC 15 generates a warning when a string initializer is too large to allow for a trailing NUL terminator byte. This type of initializer is fairly common in signature strings such as ACPI table identifiers. Fix by disabling the warning. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow for explicit control of external trust sourcesMichael Brown2025-04-151-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | We currently disable all external trust sources (such as the UEFI TlsCaCertificate variable) if an explicit TRUST=... parameter is provided on the build command line. Define an explicit TRUST_EXT build parameter that can be used to explicitly disable external trust sources even if no TRUST=... parameter is provided, or to explicitly enable external trust sources even if an explicit TRUST=... parameter is provided. For example: # Default trusted root certificate, disable external sources make TRUST_EXT=0 # Explicit trusted root certificate, enable external sources make TRUST=custom.crt TRUST_EXT=1 If no TRUST_EXT parameter is specified, then continue to default to disabling external trust sources if an explicit TRUST=... parameter is provided, to maintain backwards compatibility with existing build command lines. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use -fshort-wchar when building EFI host utilitiesMichael Brown2025-03-101-4/+5
| | | | | | | | | | | | | | | | | | | | | | | The EFI host utilities (such as elf2efi64, efirom, etc) include the EDK2 headers, which include static assertions to ensure that they are built with -fshort-wchar enabled. When building the host utilities, we currently bypass these assertions by defining MDE_CPU_EBC. The EBC compiler apparently does not support static assertions, and defining MDE_CPU_EBC therefore causes EDK2's Base.h to define STATIC_ASSERT() as a no-op. Newer versions of the EDK2 headers omit the check for MDE_CPU_EBC (and will presumably therefore fail to build with the EBC compiler). This causes our host utility builds to fail since the static assertion now detects that we are building with the host's default ABI (i.e. without enabling -fshort-wchar). Fix by enabling -fshort-wchar when building EFI host utilities. This produces binaries that are technically incompatible with the host ABI. However, since our host utilities never handle any wide-character strings, this nominal ABI incompatiblity has no effect. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow for per-architecture cross-compilation prefixesMichael Brown2024-10-291-118/+129
| | | | | | | | | | | | | | | | | | | | | | | | | We currently require the variable CROSS (or CROSS_COMPILE) to be set to specify the global cross-compilation prefix. This becomes cumbersome when developing across multiple CPU architectures, requiring frequent editing of build command lines and preventing incompatible architectures from being built with a single command. Allow a default cross-compilation prefix for each architecture to be specified via the CROSS_COMPILE_<arch> variables. These may then be provided as environment variables, e.g. using export CROSS_COMPILE_arm32=arm-linux-gnu- export CROSS_COMPILE_arm64=aarch64-linux-gnu- export CROSS_COMPILE_loong64=loongarch64-linux-gnu- export CROSS_COMPILE_riscv32=riscv64-linux-gnu- export CROSS_COMPILE_riscv64=riscv64-linux-gnu- This change requires some portions of the Makefile to be rearranged, to allow for the fact that $(CROSS_COMPILE) may not have been set until the build directory has been parsed to determine the CPU architecture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [sbi] Add support for running as a RISC-V SBI payloadMichael Brown2024-10-281-0/+2
| | | | | | | | | | | | | | | | | Add basic support for running directly on top of SBI, with no UEFI firmware present. Build as e.g.: make CROSS=riscv64-linux-gnu- bin-riscv64/ipxe.sbi The resulting binary can be tested in QEMU using e.g.: qemu-system-riscv64 -M virt -cpu max -serial stdio \ -kernel bin-riscv64/ipxe.sbi No drivers or executable binary formats are supported yet, but the unit test suite may be run successfully. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow default platform to vary by architectureMichael Brown2024-10-281-5/+12
| | | | | | | | | | | | | | | | | Restructure the parsing of the build directory name from bin[[-<arch>]-<platform>] to bin[-<arch>[-<platform>]] and allow for a per-architecture default build platform. For the sake of backwards compatibility, handle "bin-efi" as a special case equivalent to "bin-i386-efi". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Centralise dummy architecture-specific headersMichael Brown2024-09-031-5/+0Star
| | | | | | | | Simplify the process of adding a new CPU architecture by providing common implementations of typically empty architecture-specific header files. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Inhibit more linker warnings about an implied executable stackMichael Brown2023-07-041-0/+1
| | | | | | | Add .note.GNU-stack section declarations to the autogenerated PCI device ID list objects. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Silence the "creating blib.a" messageMichael Brown2023-07-041-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use separate code segment if supported by linkerMichael Brown2023-07-031-0/+7
| | | | | | | | | | | | | | | Some versions of ld will complain that the automatically created (and unused by our build process) ELF program headers include a "LOAD segment with RWX permissions". Silence this warning by adding "-z separate-code" to the linker options, where supported. For BIOS builds, where the prefix will generally require writable access to its own (tiny) code segment, simply inhibit the warning completely via "--no-warn-rwx-segments". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Simplify platform-specific client architecture definitionsMichael Brown2023-01-221-1/+0Star
| | | | | | | | | | | | | | | | Move the platform-specific DHCP client architecture definitions to header files of the form <ipxe/$(PLATFORM)/dhcparch.h>. This simplifies the directory structure and allows the otherwise unused arch/$(ARCH)/include/$(PLATFORM) to be removed from the include directory search path, which avoids the confusing situation in which a header file may potentially be accessed through more than one path. For Linux userspace binaries on any architecture, use the EFI values for that architecture by delegating to the EFI header file. This avoids the need to explicitly select values for Linux userspace binaries for each architecture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Move -Ulinux to common MakefileMichael Brown2023-01-221-0/+4
| | | | | | | The requirement to undo the implicit "-Dlinux" is not specific to the x86 architecture. Move this out of the x86-specific Makefile. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Disable dangling pointer checking for GCCMichael Brown2022-12-141-2/+4
| | | | | | | | | | | | The dangling pointer warning introduced in GCC 12 reports false positives that result in build failures. In particular, storing the address of a local code label used to record the current state of a state machine (as done in crypto/deflate.c) is reported as an error. There seems to be no way to mark the pointer type as being permitted to hold such a value, so unconditionally disable the warning. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Disable array bounds checking for GCCMichael Brown2022-12-141-2/+2
| | | | | | | | | | | | The array bounds checker on GCC 12 and newer reports a very large number of false positives that result in build failures. In particular, accesses through pointers to zero-length arrays (such as those used by the linker table mechanism in include/ipxe/tables.h) are reported as errors, contrary to the GCC documentation. Work around this GCC issue by unconditionally disabling the warning. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid invoking genkeymap.py via PerlMichael Brown2022-02-151-1/+1
| | | | | | | The build process currently invokes the Python genkeymap.py script via the Perl executable. Strangely, this appears to work. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Ensure version.%.o is always rebuilt as expectedMichael Brown2022-01-131-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fix building on broken versions of GNU binutilsMichael Brown2021-06-171-1/+2
| | | | | | | | | | | Some versions of GNU objcopy (observed with binutils 2.23.52.0.1 on CentOS 7.0.1406) document the -D/--enable-deterministic-archives option but fail to recognise the short form of the option. Work around this problem by using the long form of the option. Reported-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Ensure build ID is deterministicBernhard M. Wiedemann2021-06-141-1/+1
| | | | | | | | | | | | Commit 040cdd0 ("[linux] Add a prefix to all symbols to avoid future name collisions") unintentionally reintroduced an element of non-determinism into the build ID, by omitting the -D option when manipulating the blib.a archive. Fix by adding the -D option to restore determinism. Reworded-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Add a prefix to all symbols to avoid future name collisionsMichael Brown2021-02-271-2/+5
| | | | | | | Allow for the possibility of linking to platform libraries for the Linux userspace build by adding an iPXE-specific symbol prefix. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Compress EFI ROM imagesMichael Brown2021-02-191-1/+1
| | | | | | | | | Use the reference implementation of the EFI compression algorithm (taken from the EDK2 codebase, with minor bugfixes to allow compilation with -Werror) to compress EFI ROM images. Inspired-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove support for building with the Intel C compilerMichael Brown2021-02-121-52/+5Star
| | | | | | | | | | | | | | | | | | | Support for building with the Intel C compiler (icc) was added in 2009 in the expectation that UEFI support would eventually involve compiling iPXE to EFI Byte Code. EFI Byte Code has never found any widespread use: no widely available compilers can emit it, Microsoft refuses to sign EFI Byte Code binaries for UEFI Secure Boot, and I have personally never encountered any examples of EFI Byte Code in the wild. The support for using the Intel C compiler has not been tested in over a decade, and would almost certainly require modification to work with current releases of the compiler. Simplify the build process by removing this old legacy code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Work around distros that use -fcf-protection=full by defaultMichael Brown2021-02-041-0/+10
| | | | | | | | | | | | | | | | | | | | | | Some patched versions of gcc (observed with gcc 9.3.0 on Ubuntu 20.04) enable -fcf-protection=full by default. This breaks code that is not explicitly written to expect the use of this flag. The breakage occurs only at runtime if the affected code (such as setjmp()) happens to execute, and is therefore a particularly pernicious class of bug to be introduced into working code by a broken compiler. Work around these broken patched versions of gcc by detecting support for -fcf-protection and explicitly setting -fcf-protection=none if found. If any Ubuntu maintainers are listening: PLEASE STOP DOING THIS. It's extremely unhelpful to have to keep working around breakages that you introduce by modifying the compiler's default behaviour. Do what Red Hat does instead: set your preferred CFLAGS within the package build system rather than by patching the compiler to behave in violation of its own documentation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Work around -fPIE patched versions of gcc on all architecturesMichael Brown2021-02-041-0/+27
| | | | | | | | | | | | | | | | | | | | | | | Several distributions include versions of gcc that are patched to create position-independent executables by default. These have caused multiple problems over the years: see e.g. commits fe61f6d ("[build] Fix compilation when gcc is patched to default to -fPIE -Wl,-pie"), 5de1346 ("[build] Apply the "-fno-PIE -nopie" workaround only to i386 builds"), 7c395b0 ("[build] Use -no-pie on newer versions of gcc"), and decee20 ("[build] Disable position-independent code for ARM64 EFI builds"). The build system currently attempts to work around these mildly broken patched versions of gcc for the i386 and arm64 architectures. This misses the relatively obscure bin-x86_64-pcbios build platform, which turns out to also require the same workaround. Attempt to preempt the next such required workaround by moving the existing i386 version to apply to all platforms and all architectures, unless -fpie has been requested explicitly by another Makefile (as is done by arch/x86_64/Makefile.efi). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid spurious "make clean" when building for the first timeMichael Brown2021-02-041-29/+32
| | | | | | | | | | | | The function trace recorder build logic defaults to making "clean" a dependency of the first build in a clean checkout. This is redundant and causes problems if the build process spins up multiple make invocations to handle multiple build architectures. Fix by replacing with logic based on the known-working patterns used for the ASSERT and PROFILE build parameters. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid using awk to format build ID as hexadecimalMichael Brown2021-01-311-1/+1
| | | | | | | | | | | | | | | | | | The version of awk used in FreeBSD seems to be incapable of formatting unsigned 32-bit integers above 0x80000000 and will silently render any such value as 0x80000000. For example: echo 3735928559 | awk '{printf "0x%08x", $1}' will produce 0x80000000 instead of the correct 0xdeadbeef. This results in an approximately 50% chance of a build ID collision when building on FreeBSD. Work around this problem by passing the decimal value directly in the ld --defsym argument value. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid using sha1sum when calculating build IDMichael Brown2021-01-311-1/+1
| | | | | | | The sha1sum command may not be available on all systems. Use the POSIX-confirming cksum instead. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Check for broken elftoolchain version of objcopyMichael Brown2021-01-301-0/+7
| | | | | | | | | | | | | | | | The elftoolchain version of objcopy (as used in FreeBSD) seems to be unusable for generating a raw binary file, since it will apparently ignore the load memory addresses specified for each section in the input file. The binutils version of objcopy may be used on FreeBSD by specifying OBJCOPY=/usr/local/bin/objcopy Detect an attempt to use the unusable elftoolchain version of objcopy and report it as an error. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Replace random build ID with a deterministic oneManuel Mendez2021-01-301-1/+7
| | | | | | | | | | | Calculate the build ID as a checksum over the input files. Since the input files include $(BIN)/version.%.o which itself includes the build target name (from which TGT_LD_FLAGS is calculated), this should be sufficient to meet the requirement that the build ID be unique for each $(BIN)/%.tmp even within the same build run. Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use $(shell ...) to invoke BUILD_ID_CMDManuel Mendez2021-01-301-1/+1
| | | | | | | | | | When using $(shell), make will first invoke BUILD_ID_CMD and then have the value defined when calling $(LD). This means we get to see the _build_id when building with make V=1. Previously the build_id was figured out as a subshell command run during the recipe execution without being able to see the build_id itself. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use SOURCE_DATE_EPOCH if it existsManuel Mendez2021-01-301-0/+12
| | | | | | | | See https://reproducible-builds.org/docs/source-date-epoch/ for rationale. Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use recursive deletion for "make clean"Michael Brown2021-01-301-1/+1
| | | | | | | Directories may be left behind by failed filesystem image builds, and will not currently be successfully removed by a "make clean". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid shell brace expansion in "make clean"Michael Brown2021-01-301-3/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Drop timestamps from .a fileBernhard M. Wiedemann2021-01-291-2/+2
| | | | | | | Make the contents of $(BLIB) deterministic to allow it to be subsequently used for calculating a build ID. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Provide a testable platform macro alongside -DPLATFORMMichael Brown2020-10-161-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fix a GNUism that FreeBSD's sed(1) cannot deal withTobias Kortkamp2020-07-211-1/+1
| | | | | | | | | | | | At the moment '\s*' is silently interpreted as just 's*', but in the future it will be an error: sed: 1: "s/\.o\s*:/_DEPS +=/": RE error: trailing backslash (\) cf. https://bugs.freebsd.org/229925 Signed-off-by: Tobias Kortkamp <t@tobik.me> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Be explicit about -fcommon compiler directiveBruce Rogers2020-06-271-0/+1
| | | | | | | | | gcc10 switched default behavior from -fcommon to -fno-common. Since "__shared" relies on the legacy behavior, explicitly specify it. Signed-off-by: Bruce Rogers <brogers@suse.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Enable stack protection where possibleMichael Brown2020-06-241-11/+7Star
| | | | | | | | | | | | | | | | | | | Enable -fstack-protector for EFI builds, where binary size is less critical than for BIOS builds. The stack cookie must be constructed immediately on entry, which prohibits the use of any viable entropy source. Construct a cookie by XORing together various mildly random quantities to produce a value that will at least not be identical on each run. On detecting a stack corruption, attempt to call Exit() with an appropriate error. If that fails, then lock up the machine since there is no other safe action that can be taken. The old conditional check for support of -fno-stack-protector is omitted since this flag dates back to GCC 4.1. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Move predefined all-drivers build shortcut to MakefileMichael Brown2019-08-021-5/+0Star
| | | | | | | | | | | The (very approximate) split between Makefile.housekeeping and Makefile is that the former provides mechanism and the latter provides policy. Provide a section within Makefile as a home for predefined build shortcuts such as the existing all-drivers build. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Do not apply WORKAROUND_CFLAGS for host compilerMichael Brown2019-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | The WORKAROUND_CFLAGS list is constructed based on running tests on the target compiler, and the results may not be valid for the host compiler. The only relevant workaround required for the host compiler is -Wno-stringop-truncation, which is needed to avoid a spurious compiler warning for a totally correct usage of strncpy() in util/elf2efi.c. Duplicating the workaround tests for the host compiler is messy, as is conditionally applying __attribute__((nonstring)). Fix instead by disapplying WORKAROUND_CFLAGS for the host compiler, and using memcpy() with an explicitly calculated length instead of strncpy() in util/elf2efi.c. Reported-by: Ignat Korchagin <ignat@cloudflare.com> Reported-by: Christopher Clark <christopher.w.clark@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Workaround compilation error with gcc 9.1Valentine Barshak2019-07-221-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Compiling with gcc 9.1 generates lots of "taking address of packed member of ... may result in an unaligned pointer value" warnings. Some of these warnings are genuine, and indicate correctly that parts of iPXE currently require the CPU (or runtime environment) to support unaligned accesses. For example: the TCP/IP receive data path will attempt to access 32-bit fields that may not be aligned to a 32-bit boundary. Other warnings are either spurious (such as when the pointer is to a variable-length byte array, which can have no alignment requirement anyway) or unhelpful (such as when the pointer is used solely to provide a debug colour value for the DBGC() macro). There appears to be no easy way to silence the spurious warnings. Since the ability to perform unaligned accesses is already a requirement for iPXE, work around the problem by silencing this class of warnings. Signed-off-by: Valentine Barshak <gvaxon@gmail.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use positive-form tests when checking for supported warningsMichael Brown2018-07-081-2/+2
| | | | | | | | | | | | Some versions of gcc seem to silently accept an attempt to disable an unrecognised warning (e.g. via -Wno-stringop-truncation) but will then report the unrecognised warning if any other error occurs during the build, resulting in a potentially misleading error message. Avoid this potential confusion by using the positive-form tests in order to determine the workaround CFLAGS. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Disable gcc stringop-truncation warningsBruce Rogers2018-07-071-1/+9
| | | | | | | | | | | | | | | | | | | The gcc 8 compiler introduces a warning for certain string manipulation functions, flagging usages which _may_ not be intended. An audit of the iPXE sources indicates all usages of strncat and strncpy are as intended, so the warnings currently issued are not helpful, especially if warnings are considered errors. Fix by detecting gcc's support for -Wno-stringop-truncation and, if detected, using that option to avoid the warning. Signed-off-by: Bruce Rogers <brogers@suse.com> Modified-by: Michael Brown <mcb30@ipxe.org> Also-fixed-by: Christian Hesse <list@eworm.de> Also-fixed-by: Roman Kagan <rkagan@virtuozzo.com> Also-fixed-by: Bernhard M. Wiedemann <bwiedemann@suse.de> Also-fixed-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-05 20:52:03 +0100