Currently, glibc depends on !BR2_STATIC_LIBS in all the toolchain
variants.
However, for some architectures, glibc is the only supported libc. In
commit 3b3105328e4aa54f3cfecbf8454a9db63875d76e ("Config.in: only
allow BR2_STATIC_LIBS on supported libc/arch"), we implemented a fix
to avoid configurations were BR2_STATIC_LIBS=y with an architecture
already supported by glibc, because these configurations are
impossible. This commit 3b3105328e4aa54f3cfecbf8454a9db63875d76e
prevents from selecting BR2_STATIC_LIBS=y when the C library used for
the internal toolchain backend is glibc.
However, it introduces a discrepency between how this topic is handled
for internal and external toolchains:
- For internal toolchains, we prevent BR2_STATIC_LIBS=y if glibc is
chosen.
- For external toolchains, we allow BR2_STATIC_LIBS=y in all cases,
and it's each glibc toolchain that has !BR2_STATIC_LIBS
This commit addresses this discrepency by preventing BR2_STATIC_LIBS=y
if glibc is chosen in all cases.
Thanks to this, we can remove the !BR2_STATIC_LIBS dependency on both
the glibc package, and all glibc external toolchains.
Fixes: https://bugs.busybox.net/show_bug.cgi?id=14256 Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]>
[Thomas: update to master, fix the gen-bootlin-toolchains script, add
a comment in the static/shared choice to indicate that static is
supported only with uclibc or musl] Signed-off-by: Thomas Petazzoni <[email protected]>
support/testing/tests/toolchain/test_aarch64_64k.py:35:5: E303 too many blank lines (2)
support/testing/tests/toolchain/test_aarch64_64k.py:40:65: W605 invalid escape sequence '\('
support/testing/tests/toolchain/test_aarch64_64k.py:45:1: E302 expected 2 blank lines, found 1
support/testing/tests/toolchain/test_aarch64_64k.py:52:1: E302 expected 2 blank lines, found 1
support/testing/tests/toolchain/test_aarch64_64k.py:59:1: E302 expected 2 blank lines, found 1
support/testing/tests/toolchain/test_aarch64_64k.py:65:1: W391 blank line at end of file
Thomas Petazzoni [Tue, 26 Jul 2022 16:39:50 +0000 (18:39 +0200)]
arch/Config.in: move the binary format selection further down
Right now the "Target options" menu looks like this:
Target architecture (....)
... options related to the binary format selection ...
... options related to the architecture variant selection ...
This doesn't make much sense: the architecture variant selection
should be just below the target architecture selection. With this
commit, things will now be presented this way:
Target architecture (....)
... options related to the architecture variant selection ...
... options related to the binary format selection ...
Thomas Petazzoni [Tue, 26 Jul 2022 16:39:49 +0000 (18:39 +0200)]
package/Makefile.in: add detection for the lack of C library
We recently had several cases of architecture configurations for which
no C library was available, leading to a build failure during the gcc
build. In order to more easily detect those bogus configurations,
let's bail out very early by detecting the lack of C library
selection.
Thomas Petazzoni [Tue, 26 Jul 2022 16:39:48 +0000 (18:39 +0200)]
arch/Config.in.riscv: lp64f ABI is only supported if MMU is enabled
Even though that seems weird, the LP64F ABI is only supported when MMU
support is enabled. Indeed, as per commit 9a51381cedc16e6d70cb85e1144f6e0fa89af69a ("package/uclibc: prevent
config with unsupported RISC-V float ABI"), uClibc does not support
LP64F. But uClibc is the only C library that support RISC-V 64-bit
noMMU.
So the selection of LP64F and !MMU is impossible. Right now this
selection causes a build failure as no C library is enabled.
This commit fixes this by ensuring we cannot use LP64F when MMU
support is not available.
Instead of having the user need to figure out that 2 alsa-lib features
are needed for pipewire ALSA support, have the top-level pulseaudio
option select the relevant alsa-lib features, when alsa-lib is enabled
as already done for pulseaudio in commit 97cd3680a4cc4bc0c71bccccb1459eda4b880159
Thomas Petazzoni [Wed, 27 Jul 2022 07:30:06 +0000 (09:30 +0200)]
package/opencl-clhpp: add dependency on libopencl
Even though opencl-clhpp's build does not need libopencl, as it's just
made of headers, any user of opencl-clhpp will assume libopencl is
already installed.
Signed-off-by: Noah Huetter <[email protected]> Reviewed-by: Alistair Francis <[email protected]>
[Thomas/Arnout: change option name from
BR2_TARGET_OPENSBI_CUSTOM_MAKEOPTS to
BR2_TARGET_OPENSBI_ADDITIONAL_VARIABLES] Signed-off-by: Thomas Petazzoni <[email protected]>
Since the major release changed I've built successfully all packages that
have direct dependency to harfbuzz:
- efl
- libass
- mupdf
- pango
- qt5base
- sdl2_ttf
- supertuxkart
- vlc
- webkitgtk
- wpewebkit
The command `cmp` is used by `package/pkg-generic.mk` at commit 8623cc5deb5. This command is provided by `diffutils`, so it should be
installed on the host system.
Disable cmocka (enabled by default) to avoid the following uclibc build
failure raised since the addition of the package in commit 8aaa7ecbce1d10cbcd880c3da5e429988f96176a:
In file included from p11test_common.h:30,
from p11test_helpers.h:25,
from p11test.c:24:
/home/giuliobenetti/autobuild/run/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/usr/include/cmocka.h:2334:47: error: unknown type name 'va_list'
2334 | void vprint_message(const char* const format, va_list args) CMOCKA_PRINTF_ATTRIBUTE(1, 0);
| ^~~~~~~
Instead of having the user need to figure out that 3 alsa-lib features
are needed for pulseaudio ALSA support, have the top-level pulseaudio
option select the relevant alsa-lib features, when alsa-lib is
enabled.
In file included from ../src/modules/alsa/alsa-mixer.h:51,
from ../src/modules/alsa/alsa-ucm.c:51:
../src/modules/alsa/alsa-ucm.h:26:10: fatal error: alsa/use-case.h: No such file or directory
26 | #include <alsa/use-case.h>
| ^~~~~~~~~~~~~~~~~
Thomas Petazzoni [Tue, 26 Jul 2022 13:12:48 +0000 (15:12 +0200)]
arch: add support for configurable page size on ARM64
This commit is based on earlier work from Łukasz Stelmach
<[email protected]> to add support for different page sizes on
ARM64.
In his initial submission, Łukasz took an approach similar to this
one, i.e make it ARM64-specific. Following the feedback on the mailing
list, his second version [1] tried to generalize the logic to
configure the page size between architectures. But the general
consensus during the review process was that there wasn't much to
generalize in the end.
So, this new iteration is back to a simpler approach:
* We have new options in Config.in.arm to configure the page
size. Only 4 KB and 64 KB are supported, because our testing in
Qemu and real hardware has not allowed to get a successful setup
for 16 KB pages. We can always re-add support for 16 KB later if
that is resolved.
* The logic to define the ARCH_TOOLCHAIN_WRAPPER_OPTS options is
moved from the ARC-specific file to arch/arch.mk, and extended to
cover ARM64.
* The appropriate logic in uclibc.mk and linux.mk is added to tweak
the relevant configuration options.
* A test case is added in the runtime test infrastructure to test
building and booting under Qemu a 64 KB configuration, with all 3 C
libraries.
For the regular configuration of 4 KB pages, this commit makes one
functional change: on ARM64, -Wl,-z,max-page-size=4096 is now passed in
the compiler flags of the wrapper.
Thomas Petazzoni [Tue, 26 Jul 2022 13:12:47 +0000 (15:12 +0200)]
package/uclibc: define BR2_UCLIBC_TARGET_ARCH for ARM64
So far, BR2_UCLIBC_TARGET_ARCH had a value for all
architectures... except for ARM64. Its value is passed as ARCH= when
building uClibc... which is currently empty:
We enable TARGET_ (which doesn't exist) and set TARGET_ARCH to the
empty string.
Nobody noticed so far, and it happens to work because aarch64 is the
first architecture in the choice of architectures in
extra/Configs/Config.in in the uClibc code. So, when the architecture
is not specified, aarch64 is used.
As we are about to add some logic in uclibc.mk that will use
BR2_UCLIBC_TARGET_ARCH, we noticed this missing definition.
Thomas Petazzoni [Mon, 25 Jul 2022 15:25:21 +0000 (17:25 +0200)]
support/misc/toolchainfile.cmake.in: add definitions needed by Qt6
When compiling Qt6 applications for the target, CMake needs to have
two variables defined to find the host installation of Qt. These two
variables are unconditionally defined, regardless of whether Qt6 is
enabled in the configuration or not, as they do no harm when Qt6 is
not present/used.
Thomas Petazzoni [Mon, 25 Jul 2022 15:25:20 +0000 (17:25 +0200)]
package/qt6/qt6base: new package
This commit proposes a very minimal package for qt6base. It only
supports building QtCore, so it *really* is minimal. But that's a
starting point, which we can progressively build on top. It is based
on initial work from Peter Seiderer.
This minimal QtCore build is however sufficient to build and run
simple non-graphical Qt applications.
A number of comments:
- Even though there's only qt6base for now, many other qt6 modules
will come later on, which is why we're using the same structure as
for qt5, with a subdir for package/qt6/
- Qt6 is mutually exclusive with Qt5. Even though the library names
on the target and the location of the header files are distinct,
the host tools (qmake, moc and al.) have the same name, so at least
for now, we make them mutually exclusive.
- We've chosen to use non-bundled libraries for zlib, bb2,
double-conversion and pcre2, for both the target and the host
qt6base packages.
- Contrary to qt5 where the target package was building the host
tools, now we have a host qt6base package building the host tools,
and which is needed as a dependency for the target qt6base package.
- qt6base is using CMake. However, it strongly recommends to use
Ninja as a backend instead of make, a recommendation that we follow
in this commit. Since we don't have support for Ninja in the
cmake-package infrastructure (yet), we do this manually in
qt6base.mk itself, by passing -Gninja to CMake at configure time,
and then by using cmake --build at build time and cmake --install
at install time, using explicitly provided build and install
commands. Hopefully these can go away once we have support for
Ninja directly in cmake-package.
- We disable a number of features or external libraries using FEATURE
options. However, because there are over 400 FEATURE options in
qt6base, we didn't go all the way to explicitly disabling *all* of
them (which would be needed for both the host and target
packages). We expect that this list of explicit FEATURE options
disabling will need to grow based on the feedback of users and
issues encountered.
Peter Seiderer [Mon, 25 Jul 2022 15:25:17 +0000 (17:25 +0200)]
package/double-conversion: new package
Both the target and host variants of this package will be needed by
qt6base.
Our reading of double-conversion/utils.h in the code base seems to
show that all architectures currently supported in Buildroot (to the
exception of csky, which we intend to remove, and is anyway not
usable/testable today) are supported by double-conversion.
boot/arm-trusted-firmware: allow enabling without uboot or edk2
It should be possible to compile ARM_TRUSTED_FIRMWARE without u-boot or EDK2.
For example, one might want to produce "bl31.bin" for use as an init stub for
the Raspberry Pi 4.
- Rebased second patch
- Drop third and fourth patches (already in version)
- duktape is an optional dependency since version 1.0.0 and
https://github.com/meetecho/janus-gateway/commit/fab4215b7826638660eba2147bb772dd57fed10c
- gengetopt is not a dependency since version 1.0.1 and
https://github.com/meetecho/janus-gateway/commit/c21500c02e93e4b08c5242d0f0066d26ffc9f1a9
Fix the following build failure with gcc 4.8 raised since bump to
version 1.0.0 in commit ib832f6eb9d86920907c50901a99f13b44dd94647 and
https://github.com/google/fscryptctl/commit/9dba7224cbde07df25ba01146a2f6fb897bb9e56:
fscryptctl.c: In function 'string_to_mode':
fscryptctl.c:214:3: error: 'for' loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < ARRAY_SIZE(mode_strings); i++) {
^
Currently, this option doesn't do anything. It only adds
--enable-plugins --enable-lto to the configure flags, but doesn't
disable them if it is not set. Since both of these default to enabled,
plugins and lto are effectively always enabled.
There really is no need to make this configurable: it adds a bit of size
and build time to host-gcc, but we don't care about that for host tools.
It's still up to individual builds to enable the LTO options.
Therefore, remove the option entirely. For clarity, explicitly pass
--enable-plugins --enable-lto to configure.
No legacy handling is added for the removed option. Since the behaviour
hasn't actually changed (independently of whether the option was enabled
or not), there's no point bothering the user with a legacy option.
elf2flt was linking with libdl depending on this option. Since the
option doesn't do anything, this is probably not needed. Still, to avoid
breaking things, and because linking with libdl doesn't cost us anything
anyway, always link with libdl.
Currently, this option doesn't do anything. It only adds
--enable-plugins --enable-lto to the configure flags, but doesn't
disable them if it is not set. Since both of these default to enabled,
plugins and lto are effectively always enabled.
There really is no need to make this configurable: it adds a bit of size
and build time to host-binutils, but we don't care about that for host
tools. It's still up to individual builds to enable the LTO options.
Therefore, remove the option entirely. For clarity, explicitly pass
--enable-plugins --enable-lto to configure.
configs/*: use BR2_ENABLE_LTO to enable LTO instead of BR2_GCC_ENABLE_LTO
BR2_GCC_ENABLE_LTO only enables LTO in the toolchain, not in packages.
Use BR2_ENABLE_LTO instead to enable it in packages as well.
Note that BR2_GCC_ENABLE_LTO is currently non-functional (LTO is still
enabled in the toolchain even if it's not set), so we *do* have LTO
available in the toolchain.
Note that the option has no effect at all on these defconfigs anyway,
since they don't contain any package that is affected by the
BR2_ENABLE_LTO option. Still, it makes sense to enable it for these
really memory-constrained targets for when packages are added.
package/*: use BR2_ENABLE_LTO to enable LTO instead of BR2_GCC_ENABLE_LTO
The BR2_GCC_ENABLE_LTO controls whether or not LTO is available in the
(internal) toolchain - it shouldn't be used to control whether packages
are built with LTO. Use the new BR2_ENABLE_LTO option instead.
Config.in: add new option BR2_ENABLE_LTO to globally enable LTO
Some packages have a configure option to enable LTO. Add a global option
to enable/disable this in packages.
Note that we could instead (or in addition) pass -flto directly to the
compiler in the toolchain wrapper, but that has a *much* bigger impact,
so for the time being let's not do that.
No toolchain dependency is added for this, because all toolchains now
support LTO.
- LTO support was merged in GCC years before 4.6 (our minimal version)
was released.
- Our oldest external toolchain, Sourcery ARM 2014.05, has LTO support.
- For our internal toolchains, it is supposedly regulated by
BR2_GCC_ENABLE_LTO. However, that option only *enables* it - it
doesn't disable LTO support when it's not provided. Since LTO support
defaults to enabled for a long time already in GCC, in practice all
Buildroot-generated toolchains do support LTO.
package/gnuradio: use external volk instead of the internal one
Until recent releases GNURadio was shipped with volk as a
submodule. Even though we still use 3.8.x, with the newer 3.9 and
3.10, volk is no longer available as a submodule, and it is needed to
build it separately.
In order to prepare for this, this patch disable the internal volk,
and adds a dependency to the corresponding package, to use
unconditionnaly the one built by Buildroot.
David GOUARIN [Tue, 4 Jan 2022 21:55:41 +0000 (15:55 -0600)]
package/freeradius-server: new package
FreeRADIUS is an open source server which implements
a protocol for remote user Authorization, Authentication
and Accounting.
There are many modules. All modules without dependencies are enabled.
The modules with a dependency that we have are automatically enabled if
the dependency is enabled. Modules with dependencies we don't support
are explicitly disabled.
The configure script always looks in host directories for libraries, so
it is essential to explicitly disable everything that is not actually
provided.
Signed-off-by: David GOUARIN <[email protected]> Signed-off-by: Kalpesh Panchal <[email protected]> Signed-off-by: Matt Weber <[email protected]>
[Arnout:
- remove second patch, superseded by other patches;
- add upstream links to patches;
- add more patches to avoid looking in host directories;
- explicitly add dependency on !static inherited from talloc (redundant
with glibc, but future-safe);
- simplify Config.in comment;
- check hash with PGP signature;
- add conf opts for runtime paths;
- add conf opts to disable unsupported modules;
- add more optional dependencies;
- enable/disable all modules that use a dependency;
- search defaults file in /etc/default, not /etc/sysconfig.
] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]>
Vincent Fazio [Tue, 26 Jul 2022 15:15:36 +0000 (10:15 -0500)]
package/mesa3d-headers: bring back the installation of dri.pc
With the version bump to 22.x, the dri.pc file was no longer deployed as
it was believed to not be provided.
While it was temporarily missing from upstream as part of deprecating
the classic driver, it was reintroduced prior to the 22.0 release via:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/3ae3569d822c2546c4c748090f8a6c8016f763ea
This file is still necessary to build Xorg server. See previous commits: 9014c21cac 7468b60e7c
Fixes: 6c25d1099 ("package/{mesa3d, mesa3d-headers}: bump version to 22.1.3") Signed-off-by: Vincent Fazio <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
eap-tls.c: In function 'ssl_msg_callback':
eap-tls.c:1284:10: error: 'SSL3_RT_HEADER' undeclared (first use in this function); did you mean 'SSL3_RT_ALERT'?
1284 | case SSL3_RT_HEADER:
| ^~~~~~~~~~~~~~
| SSL3_RT_ALERT
Giulio Benetti [Fri, 14 Jan 2022 10:55:11 +0000 (11:55 +0100)]
package/sg3_utils: fix build failure due to gcc bug 104028
The sg3_utils package exhibits gcc bug 104028 when built for the M68K
architecture with optimization enabled, which causes a build failure.
As done for other packages in Buildroot work around this gcc bug by
setting optimization to -O0 if BR2_TOOLCHAIN_HAS_GCC_BUG_104028=y like we
already do for BR2_TOOLCHAIN_HAS_GCC_BUG_85180=y.
sg3_utils package fails to build for the M68K architecture with optimization
enabled with gcc = 10.3.0 and it's still present in gcc = 11.1.0:
http://autobuild.buildroot.net/results/c49300d12a209b18f41d389f092324592b881277/
It's been reported upstream:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104028
The commit [1] removed the Config.in.host file and moved the arm, sh,
sparc, xtensa and riscv-64 architectures dependencies. But this list
doesn't contain all elf2flt supported architectures and this breaks
the host-gcc-initial build for m68k.
Since BR2_BINFMT_FLAT is only available on no MMU case, we can rely on
BR2_USE_MMU option and remove the architecture list.
Note: SH without MMU support has been removed by [2], sparc requires
an MMU since at least [3].
In commit fd839aeb7f40596e60bc53a96b7a65892924cc26 ("package/glibc:
introduce and use BR2_PACKAGE_GLIBC_ARCH_SUPPORTS and
BR2_PACKAGE_GLIBC_SUPPORTS") we moved the Config.in logic about glibc
dependencies from toolchain/toolchain-buildroot/Config.in into
package/glibc/Config.in.
Unfortunately, it is not possible to move the Config.in comments that
tell the user, within the choice..endchoice for the C library why
glibc is not currently selectable, so we had to keep them in
toolchain/toolchain-buildroot/Config.in.
Turns out that the comments were out of sync with the dependencies,
and two comments were missing. This commit adds the missing ones, and
adds a comment in package/glibc/Config.in explaining that we need to
be careful about updating toolchain/toolchain-buildroot/Config.in as
well.
../output-1/build/pulseaudio-16.1/meson.build:1:0: ERROR: Unknown compiler(s): [['/home/autobuild/autobuild/instance-1/output-1/per-package/pulseaudio/host/bin/powerpc64-buildroot-linux-gnu-g++']]
The following exception(s) were encountered:
Running "/home/autobuild/autobuild/instance-1/output-1/per-package/pulseaudio/host/bin/powerpc64-buildroot-linux-gnu-g++ --version" gave "[Errno 2] No such file or directory: '/home/autobuild/autobuild/instance-1/output-1/per-package/pulseaudio/host/bin/powerpc64-buildroot-linux-gnu-g++'"
Thomas Petazzoni [Tue, 26 Jul 2022 08:14:32 +0000 (10:14 +0200)]
package/avocado: fix license
In commit ef321ff4a90acf2133ee29d5fd2a65fc9906c748 ("package/avocado:
new package") the license information that was introduced was
incorrect. The license is GPL-2.0, not Apache-2.0.
According to the LICENSE file:
Most files in Avocado are released under the GPLv2 with a "and any later
version" clause (GPLv2+), but some files are explicitly bound to the
version 2 of the license and therefore that's the official license of
the project itself. The header on each individual file contains
information about the GPL version that applies to it.
/nvmedata/autobuild/instance-17/output-1/host/lib/gcc/sparc-buildroot-linux-uclibc/10.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: pkcs11_tool-pkcs11-tool.o: in function `sign_verify_openssl.constprop.0':
pkcs11-tool.c:(.text+0x6b00): undefined reference to `EVP_ripemd160'
Signed-off-by: Guillaume W. Bres <[email protected]>
[Arnout: don't remove original author from the patch] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]>
Andreas Ziegler [Mon, 25 Jul 2022 12:30:02 +0000 (14:30 +0200)]
package/mpd: add io_uring optional dependency
Since version 0.22 mpd provides an option to use the io_uring kernel interface
for asynchronous access to local files. Buildroot has the necessary library
(package/liburing) since commit 03ca6f4e39874583060317e7e15e9e360220877e.
Add an optional dependency on liburing to enable asynchronous file access using
the kernel io_uring interface.
shellcheck is already in use to check SysV init scripts.
Currently its results can be affected by the existence of a
.shellcheckrc file in any parent directory.
For instance, in this example:
(1) /path/.shellcheckrc
(2) /path/to/.shellcheckrc
(3) /path/to/buildroot
the configs from file (1) are ignored and the configs from file (2)
override the default values from the shellcheck binary.
So the config file affects the check-package result for SysV scripts.
Avoid this reproducibility issue by adding an empty config file to the
buildroot topdir.
It can also eventually contain configs (different from default values
from sheelcheck) that we want as a standard to all shell scripts tested
by check-package.
Zeek is a powerful network analysis framework that is much different
from the typical IDS you may know. (Zeek is the new name for the
long-established Bro system.)
Signed-off-by: Fabrice Fontaine <[email protected]>
[Arnout:
- select python3 instead of depends;
- patch python path in post-patch instead of post-install] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]>
The analysis made back then is probably not entirely correct - the issue
only seems to occur with GCC8, not with any earlier or later version,
which hints at a compiler bug. Since the error involves some
LTO-generated functions, the trigger is probably the -flto=4.
Whatever the exact issue is, it is avoided if we make sure that our
CFLAGS replace the default ones instead of being added to them.
Currently, they are added because the configure script doesn't properly
detect that CFLAGS was set.
Add a patch (sent upstream months ago, but it didn't appear in the
release that has been done since then) that makes sure CFLAGS is
properly detected.
Heiko Thiery [Thu, 24 Jun 2021 12:57:03 +0000 (14:57 +0200)]
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <[email protected]>
[Thomas: pretty much rework the entire implementation and how the
result is presented.] Signed-off-by: Thomas Petazzoni <[email protected]>
package/luasyslog: fix build when host root directory is /usr
Fix the following build failure when host root directory is /usr which
is raised since bump to version 2.2.0 in commit caa32ac237909999eb6e0bd3616ef4440190970a:
This failure is raised because lua script directory is "found" and
"fixed" to
${prefix}/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/host/usr/share/lua/5.3
because of the following test in ax_lua.m4:
dnl Try to find a path with the prefix.
_AX_LUA_FND_PRFX_PTH([$LUA], [$ax_lua_prefix], [package.path])
AS_IF([test "x$ax_lua_prefixed_path" != 'x'],
[ dnl Fix the prefix.
_ax_strip_prefix=`echo "$ax_lua_prefix" | sed 's|.|.|g'`
ax_cv_lua_luadir=`echo "$ax_lua_prefixed_path" | \
sed "s,^$_ax_strip_prefix,$LUA_PREFIX,"`
])
1 #ifndef __gles2_gl2ext_h_
2 #define __gles2_gl2ext_h_ 1
3
4 #if 0
5 #pragma qt_no_master_include
6 #pragma qt_sync_skip_header_check
7 #pragma qt_sync_stop_processing
8 #endif
9
10 #ifdef __cplusplus
11 extern "C" {
12 #endif
13
14 #ifndef __gl3_h_
15 /* These types are defined with reference to <inttypes.h>
16 * in the Apple extension spec, but here we use the Khronos
17 * portable types in khrplatform.h, and assume those types
18 * are always defined.
19 * If any other extensions using these types are defined,
20 * the typedefs must move out of this block and be shared.
21 */
22 typedef khronos_int64_t GLint64;
23 typedef khronos_uint64_t GLuint64;
24 typedef struct __GLsync *GLsync;
25 #endif
The problem is that rpi-userland doesn't define GLsync, and both
GStreamer and Qt have their own definition of GLsync in this case, but
they are not the same.
We reported this issue to:
* rpi-userland, to get the headers updated:
https://github.com/raspberrypi/userland/issues/469#issuecomment-1193864294
* gstreamer, to get their bogus definition of GLsync fixed:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/973
In the mean time, fix this by adding the missing definitions to
rpi-userland, so that GStreamer and Qt don't try to provide their own.
package/glibc: fix struct stat for microblaze with largefile
On microblaze, there is a separate version of struct stat for largefile
and for non-largefile. When the struct was updated to include the
st_mtim, st_atim and st_ctim members for POSIX, the largefile version
was forgotten. Since we only use largefile in Buildroot, that means that
microblaze didn't have these members in struct stat. This breaks the
build of some packages.
Change the define around st_mtim etc. to __USE_XOPEN2K8 to enable it in
posix context (i.e. by default).
Goran Rađenović [Wed, 17 Feb 2021 16:09:58 +0000 (17:09 +0100)]
package/qt5/qt5doc: add package with qt quick demos
Since qt 5.12, quick demos are moved in the qt5doc package.
In order to use quick demos, qt5doc has to be built.
qt5doc is a bit misleading name for the package, while it's
basic content are the quick demos. qdoc tool itself is a part
of qt5tools.
The examples need to be enabled for this package to do anything (because
we don't build the docs themselves), so select it
Signed-off-by: Goran Rađenović <[email protected]>
[Arnout:
- fix check-package warnings;
- update to Jan 31 2022 version of kde/5.15 branch;
- add select of BR2_PACKAGE_QT5BASE_EXAMPLES;
- add hash for license file] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]>
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/i586-buildroot-linux-musl/9.3.0/../../../../i586-buildroot-linux-musl/bin/ld: /home/buildroot/autobuild/instance-1/output-1/host/i586-buildroot-linux-musl/sysroot/usr/lib/libreadline.a(display.o): in function `_rl_move_cursor_relative':
display.c:(.text+0xbb5): undefined reference to `tputs'
Nicolas Tran [Thu, 19 May 2022 08:28:00 +0000 (10:28 +0200)]
package/hyperfine: new package
hyperfine is a benchmark tool written in Rust. It evaluates
execution time of a command passed in arguments and make
a relative comparison if multiple arguments are used at the
same time.
It can be convinient for purposes of Rust-written systems as
it runs in a stable version of Rust.
The package has been checked with correct formatting and
without typos:
./utils/check-package package/hyperfine/*
A CI test was run on gitlab.com to verify toolchain compatibilities.
Peter Seiderer [Sun, 14 Mar 2021 22:32:07 +0000 (23:32 +0100)]
package/batman-adv: enable B.A.T.M.A.N. V protocol by default
As upstream enables CONFIG_BATMAN_ADV_BATMAN_V option since
2018.2 by defaullt ([1]) honor this in buildroot and do
the same (and remove the legacy experimental comment accordingly -
although upstream docs still mention it as legacy, that's really an
oversight, the community considers it the go-to protocol for years now).
package/x11r7/xdriver_xf86-video-mga: bump version to 2.0.1
Removed patch (and autoreconf) which was commited upstream:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/commit/f227f2f286123a9ca64b567783825a2c18b87971
COPYING hash changed because of a spelling fix: MERCHANTIBILITY ->
MERCHANTABILITY. Note that the latter is also the spelling used in the
official MIT license.
projects / buildroot-mgba.git / log