When EDK2 OVMF is built with debug, messages are printed to
IO port 0x402. Those messages are not shown in the normal
Qemu emulated serial port. Enabling this option will print
debug messages on the emulated serial port, potentially
mixing messages with UEFI serial console output.
See OVMF README:
https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
This option has been useful to debug problems such as [1], in which the
emulator was hanging at startup without any log. Enabling this option
show the debug message on the console, before hanging:
...
PlatformCpuCountBugCheck: Present=0 Possible=1
PlatformCpuCountBugCheck: Broken CPU hotplug register block found. Update QEMU to version 8+, or
PlatformCpuCountBugCheck: to a stable release with commit dab30fbef389 backported. Refer to
PlatformCpuCountBugCheck: <https://bugzilla.tianocore.org/show_bug.cgi?id=4250>.
...
[1] http://lists.busybox.net/pipermail/buildroot/2023-July/670807.html
Signed-off-by: Julien Olivain <ju.o@free.fr>
Tested-by: Romain Naour <romain.naour@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Upstream added the possibility to build with system-provided pcre2 back
in 2014:
016bd4fc5f
The policy in Buildroot is to use system-provided libraries rather than
bundled ones, but we missed that opportunity when we introduced mariadb
back in 2016, with commit 2cd86cdbfc (mariadb: new package).
Fix that now.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Currently, there is no MMX support for modern GEODE processors in Buildroot.
Yet, some packages like ffmpeg can leverage it when the package is built.
Signed-off-by: Cherniaev Andrei <dungeonlords789@naver.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The test_pixz.py test was initially written as a standalone test.
The commit cf132a13
"support/testing/tests/package/test_compressor_base.py: new helper class"
introduced a helper class for testing data compression programs.
This commit rewrites this test to use this helper class.
The test coverage is mostly the same as before the rewrite. Notable
differences are:
- the test file is slightly smaller for faster testing,
- its content layout also slightly different.
Cc: Vincent Stehlé <vincent.stehle@laposte.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commits adds support for building a RISC-V toolchain with the
vector extension, available since gcc 12.
Signed-off-by: Tianrui Wei <tianrui@tianruiwei.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fluent-bit is written in pure c, so drop any cxx handling. Only the wasm
part needs c++, but that one doesn't need the fixes which are now dropped.
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Luajit was not used at all when it was selected, instead fluent-bit
recompiled it without taking care of the complexities that were
handled in the luajit package. Fix this by linking dynamically to the
buildroot provided version.
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Call these unconditionally to make sure proper support is flagged so
proper dependencies are included in the resultant filesystem.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Previously, it was possible for external toolchains to be used that had
support for languages or libraries that Buildroot was not aware of.
If Buildroot is not made aware of this support, it will not know to copy
the requisite libraries into the filesystem.
This is problematic as packages may perform their own checks [0] to find
out what the toolchain supports and builds will link against libraries
from the toolchain but will be missing dependencies in the filesystem.
Now, the support helpers alert the user when a toolchain supports a
language or library that has not been set in the Buildroot configuration.
Also, while we're here, add `-ffree-form` to the Fortran check to
suppress a meaningless warning.
[0]: https://bugs.busybox.net/show_bug.cgi?id=15634
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The fragments provided by toolchains.bootlin.com were incorrectly
flagging toolchains as not having OpenMP support while they had it
[0]. This has been fixed in toolchains.bootlin.com, so a run of
gen-bootlin-toolchains has allowed to adjust the toolchain definitions
in Buildroot, leading to this commit.
OpenMP support needs to be flagged so the proper libraries get copied
into the resultant filesystem to avoid missing dependencies [1].
[0]: https://github.com/bootlin/toolchains-builder/issues/60
[1]: https://bugs.busybox.net/show_bug.cgi?id=15634
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
check-package is verifying the alphabetic ordering of package names,
not directory, so package/llvm-project/clang/Config.in should be
sorted as "clang" and not "llvm-project".
Fixes:
package/Config.in:2130: Packages in: menu "Other",
are not alphabetically ordered;
correct order: '-', '_', digits, capitals, lowercase;
first incorrect package: clang
In:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4718833134
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since upstream Linux commit 6898e60f709b0047206110d3ec9f4612210e3ff7
("perf build: If libtraceevent isn't present error the build") present
in Linux 6.4 and newer, Linux will fail to build if libtraceevent is not
present. Since we do not currently have support for libtracevent in
buildroot, pass NO_LIBTRACEVENT=1 to get perf to build again.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
By default, module libraries have a suffix based on cpython version + host
architecture: this is fine for a native compile when these libraries are used on
the same computer (or similar computers). But when target architecture is not
the same python is unable to find libraries due to the wrong suffix and produces
unclear errors messages:
# python3
Python 3.11.3 (main, Jun 19 2023, 14:15:44) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from gnuradio import blocks
Traceback (most recent call last):
File "/home/xxx/buildroot/output/build/gnuradio-3.10.4.0/gr-blocks/python/blocks/__init__.py", line 18, in <module>
ModuleNotFoundError: No module named 'gnuradio.blocks.blocks_python'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/xxx/buildroot/output/build/gnuradio-3.10.4.0/gr-blocks/python/blocks/__init__.py", line 22, in <module>
ModuleNotFoundError: No module named 'gnuradio.blocks.blocks_python'
>>>
By adding _PYTHON_SYSCONFIGDATA_NAME="$(PKG_PYTHON_SYSCONFIGDATA_NAME)" at configure time, sysconfig will
return correct informations (target architecture) instead of host architecture.
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Adjust comments in the Go package to improve clarity:
Config.in.host:
- Add comment mentioning list of supported architectures.
go.mk:
- Reword comment re: copying src/ to host/
- the previously linked issue is not relevant.
- instead: mention that src/ is needed for stdlib.
- Adjust comment re: adjusting file timestamps.
- mention this is needed to avoid rebuilding stdlib
Signed-off-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
