[pull] master from buildroot:master#911
Merged
pull[bot] merged 23 commits intomir-one:masterfrom Mar 13, 2026
Merged
Conversation
Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Danomi Manchego <danomimanchego123@gmail.com> Signed-off-by: Romain Naour <romain.naour@smile.fr>
Version 2.1.x has introduced a cmake-based build, and upstream strongly
recomends using it over the legacy Makefiles, which will ultimately be
retired.
So we do the switch, which cause quite some noise in the .mk file, but
at the same time allows for a bit of cleanup in the build process, as we
can now use the cmake-package infra.
Mosquitto now wants to peek into the malloc() internals for memory
tracking, and that only works on systems with an MMU (uClibc-ng does not
expose it for noMMU builds, as it's part of its malloc-standard
implementation).
Static-only builds are broken, even when only building the library. This
seems beyond a simple repair, so just require shared libs now (since
we're requiring an MMU as well, requiring shared libs is not too much of
an additional burden).
cJSON is now a required dependency, used in common parts of the code
(not just for the plugins).
There are a few options that we forcibly disable; they'll get addressed
in followup patches.
There are still a few build failures that are difficult to account for
(except):
$ printf 'BR2_PACKAGE_MOSQUITTO=y\n' >mosq.cfg
$ ./utils/docker-run ./utils/test-pkg -d $(pwd)/run-tests -c mosq.cfg -p mosquitto
br-arm-full-static [5/6]: FAILED
=> old uClibc-ng, would need __GNU_SOURCE (with dunder) to define
getrandom(); no longer needed since uClibc-ng 1.0.50; would need
openssl otherwise
bootlin-aarch64-glibc-old [6/6]: FAILED
=> really old glibc, missing getrandom(); would need openssl
Drop our existing patches, they've either been applied upstream, or are
no longer needed. Add new patches to fix various build issues
(submission upstream pending the signature of the CLA..,).
Thanks a lot to Titouan for providing his initial work on the update!
Some of his findings ended up in this patch. 👍
Note: by lack of a trusted path back to the PGP key that signed the
archive, the comment was dropped, as checking a signature without a
trust-chain does not make much sense...
Co-developped-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Titouan Christophe <titouan.christophe@mind.be>
[Romain: remove "mosquitto broker" comment for static builds]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
mosquitto_pub/sub/rr can be handy to test a broker from the command line, but they can get superfluous when only the broker is required on the target. Add an option to enable or disable them. Make that new option enabled by default to keep backward compatibility with previous (def)config files. Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Titouan Christophe <titouan.christophe@mind.be> Signed-off-by: Romain Naour <romain.naour@smile.fr>
mosquitto_{ctrl,db_dump,passwd,signal} can be handy to interact with
the mosquitto broker during development, but are usually unnecessary
on the target.
Add an option to enable or disable them. Make that new option enabled
by default when the broker is enabled, to keep backward compatibility
with previous (def)config files.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Fiona Klute <fiona.klute@gmx.de>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Mosquitto 2.1.x adds the possibility to use a builtin websocket implementation, as an alternative to using libwebsockets. When using libwebsockets as the implementation, only the broker supports websockets, and CLI tools do not; only when using the builtin one are websockets usable with CLI tools (and the broker, of course). Add a choice to select what type of websockets support to enable, if any. Since the builtin implementation is still new, we keep the libwebsockets one available. Since this inverts the dependency logic to libwebsockets, we can't provide a backward compatibility with existing (def)config files. Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Titouan Christophe <titouan.christophe@mind.be> Signed-off-by: Romain Naour <romain.naour@smile.fr>
The mosquitto broker (not the library) can have listeners configured to serve HTTP requests; it can optionally accept (some) HTTP API requests on such listeners. Add a new option to enable the availability of http_pi. Note that we do not just depend on libmicrohttpd to be enabled, because the HTTP API is a security boundary, and enabling it must be an explicit decision. Co-developped-by: Titouan Christophe <titouan.christophe@mind.be> [yann.morin@orange.com: make it an explicit option] Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Titouan Christophe <titouan.christophe@mind.be> Signed-off-by: Romain Naour <romain.naour@smile.fr>
Until version 2.0.x, support for using static password or ACL files, was builtin to the broker. With version 2.1.x, two new plugins have been introduced to replace the builtin support, which is now deprecated and will get removed in the next version. Add two new configuration options for those plugins. We decided to do a single commit, rather than one per option, because they are relatively tied together (ACL needs passwords, at least). We also choose to make those options enabled by default, because the traditional way to configure mosquitto is to use static files for authentication and authorization, and the builtin support if now deprecated in favour for the plugins. The usual ifeq-else-endif conditional block is a bit verbose when just setting an option ON or OFF, when no additional dependency is needed. Instead, use the not-unusual $(if)-inline one-liner. For consistency, switch the existing dynamic-security plugin to use that one-liner too. Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Titouan Christophe <titouan.christophe@mind.be> Signed-off-by: Romain Naour <romain.naour@smile.fr>
That plugin can be used instead of the builtin support to persist the mosquitto state across restarts. Note that this plugin has a dependency, so we don't use the $(if) one-liner. Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Titouan Christophe <titouan.christophe@mind.be> Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Titouan Christophe <titouan.christophe@mind.be> Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Titouan Christophe <titouan.christophe@mind.be> Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Titouan Christophe <titouan.christophe@mind.be> Signed-off-by: Romain Naour <romain.naour@smile.fr>
This commit adds the Neoverse-V1 core, which is an armv8.4a ISA. See: [1] [2]. This CPU support was added in GCC 11. See [3] [4] [5]. This CPU supports Aarch64 at all exception levels (EL0 to EL3). It also supports Aarch32 only in EL0 (user-space). This means it's technically possible to compile Aarch32 code. GCC has the support to do so. Since Buildroot recompiles a full system (ATF, Kernel, user-space) this support has limited value. This is why this CPU is limited to 64bit builds only. Qemu added neoverse-v1 support in upstream commit [6], first included in v8.1.0. [1] https://developer.arm.com/Processors/Neoverse%20V1 [2] https://developer.arm.com/documentation/101427/0102/Functional-description/Introduction/About-the-core [3] https://gcc.gnu.org/gcc-11/changes.html#arm-targets [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;hb=releases/gcc-11.1.0#l141 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c9d56eb777552ac5ee0c281e1f6e34b6fe929b77 [6] https://gitlab.com/qemu-project/qemu/-/commit/c74138c6c040b62e941326a4fbb25a93fdd35b72 Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds the Neoverse-V2 core, which is an armv9.0a ISA. See: [1] [2]. This CPU support was added in GCC 13. See [3] [4] [5]. This CPU supports Aarch64 at all exception levels (EL0 to EL3). It also supports Aarch32 only in EL0 (user-space). This means it's technically possible to compile Aarch32 code. GCC has the support to do so. Since Buildroot recompiles a full system (ATF, Kernel, user-space) this support has limited value. This is why this CPU is limited to 64bit builds only. Note: at the time of this commit, the latest binutils v2.46 does not include a Neoverse-V2 support for its '-mcpu' option. See [6]. This is not an issue because gcc will call the "as" assembler with the relevant "-march=armv9-a+EXTENSION..." options. Binutils supports "armv9-a" since upstream commit [7] (first included in 2.38), and the oldest Binutils version in Buildroot is 2.44. [1] https://developer.arm.com/Processors/Neoverse%20V2 [2] https://developer.arm.com/documentation/102375/latest/ [3] https://gcc.gnu.org/gcc-13/changes.html#aarch64 [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;hb=releases/gcc-13.1.0#l184 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=14d4b4fb12041dde1511262b926662929196c3fe [6] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-aarch64.c;h=cd76163488c48e45d43c35b2704d637999d51015;hb=3e93b95c3ae3f00a0283ddbab8029cbc07d96aff#l10833 [7] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=d5007f0280d881a8add44e6a68a3f536e138244c Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds the Neoverse-V3 core, which is an armv9.2a ISA. See: [1] [2]. This CPU support was added in GCC 15. See [3] [4] [5]. This CPU supports Aarch64 only at all exception levels (EL0 to EL3). Note: at the time of this commit, the latest binutils v2.46 does not include a Neoverse-V3 support for its '-mcpu' option. See [6]. This is not an issue because gcc will call the "as" assembler with the relevant "-march=armv9.2-a+EXTENSION..." options. Binutils supports "armv9.2-a" since upstream commit [7] (first included in 2.38), and the oldest Binutils version in Buildroot is 2.44. [1] https://developer.arm.com/Processors/Neoverse%20V3 [2] https://developer.arm.com/documentation/107734/0002/The-Neoverse--V3--core/Neoverse--V3--core-features [3] https://gcc.gnu.org/gcc-15/changes.html#aarch64 [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;hb=releases/gcc-15.1.0#l221 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=729000b90300a31ef9ed405635a0be761c5e168b [6] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-aarch64.c;h=cd76163488c48e45d43c35b2704d637999d51015;hb=3e93b95c3ae3f00a0283ddbab8029cbc07d96aff#l10833 [7] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=3518022233e6b757c57d3deb7723fd91214fe036 Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds the Neoverse-V3AE (Automotive Enhanced) core, which is an armv9.2a ISA. See: [1] [2]. This CPU support was added in GCC 15. See [3] [4] [5]. This CPU supports Aarch64 only at all exception levels (EL0 to EL3). This CPU is present in NVIDIA Jetson Thor / Tegra T264 [6]. Note: at the time of this commit, the latest binutils v2.46 does not include a Neoverse-V3AE support for its '-mcpu' option. See [7]. This is not an issue because gcc will call the "as" assembler with the relevant "-march=armv9.2-a+EXTENSION..." options. Binutils supports "armv9.2-a" since upstream commit [8] (first included in 2.38), and the oldest Binutils version in Buildroot is 2.44. [1] https://developer.arm.com/Processors/Neoverse%20V3AE [2] https://developer.arm.com/documentation/101595/0002/The-Neoverse-V3AE--core/Neoverse-V3AE--core-features [3] https://gcc.gnu.org/gcc-15/changes.html#aarch64 [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;hb=releases/gcc-15.1.0#l222 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7ca2a803c4a0d8e894f0b36625a2c838c54fb4cd [6] https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-thor/ [7] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-aarch64.c;h=cd76163488c48e45d43c35b2704d637999d51015;hb=3e93b95c3ae3f00a0283ddbab8029cbc07d96aff#l10833 [8] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=3518022233e6b757c57d3deb7723fd91214fe036 Signed-off-by: Julien Olivain <ju.o@free.fr>
https://www.php.net/ChangeLog-8.php#8.5.4 https://news-web.php.net/php.announce/486 Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Julien Olivain <ju.o@free.fr>
The trap was initially introduced in c5fa930 (core/br2-external: properly report unexpected errors), in 2017, to catch all unexpected errors, back when a single file was generated, and errors emitted to stderr. Since commit d027cd7 (core: generate all br2-external files in one go), in 2019 the single output file 'ofile' is no longer created, as multiple output files were then introduced, while messages for *expected errors* were redirected to a Makefile variable assignment emitted on stdout, at which point the script just exits (in error); expected failures only occur in do_validate(). Unexpected errors can only occur on failure to create, or write to, output files, either '.br2-external.mk' in do_validate() or do_mk(), or any of the kconfig fragments in do_kconfig(). Cause for failure to create those can only be a no-space-left-on-device condition, as they are created in a directory that was just created by the script earlier in main(), and thus has the necessary mode; failure to create that directory is now caught explicitly. A trap on ERR is not called when the shell exits explicitly with a call to 'exit', thus, only failures to create or write to output file would be caught. In that case, we are better off not trying to write to those files anyway: failure to create the file would already be reported by the shell on stderr, while disk-full would not allow to store the output anyway... In any case, the script exits in error, which is going to be caught by the caller, which will terminate. So, drop the trap altogether. As a side effect, that squelches a shellcheck error. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Romain Naour <romain.naour@smile.fr>
Boring changes: either do what shellcheck suggested, or comment why we don't want to fix the code. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Romain Naour <romain.naour@smile.fr>
Specifying a list of br2-external trees is poorly documented, and the
only example uses a colon to separate the br2-external paths.
Adding the support for colon-separated list is the biggest mistake that
was made when introducing support for multiple br2-external [0]. Indeed,
both space and colon can be used to separate entries in the list, and it
is also possible to mix the two. However, internally, the list is stored
as a space-separated list, and all the code will split on spaces.
Besides, all other lists in Buildroot are a space-separated:
BR2_ROOTFS_DEVICE_TABLE
BR2_ROOTFS_STATIC_DEVICE_TABLE
BR2_TARGET_TZ_ZONELIST
BR2_ROOTFS_USERS_TABLES
BR2_ROOTFS_OVERLAY
BR2_ROOTFS_PRE_BUILD_SCRIPT
BR2_ROOTFS_POST_BUILD_SCRIPT
BR2_ROOTFS_POST_FAKEROOT_SCRIPT
BR2_ROOTFS_POST_IMAGE_SCRIPT
...
So, using colons is odd.
The fact that BR2_EXTERNAL is passed on the command line rather than
being a Kconfig item is not a reason enough to justify that it be
colon-separated.
Change the documentation to only mention using a space-separated list.
Of course, for backward compatibility, we keep the code as-is to accept
a colon-separated list, but we just do not advertise it.
Note that keeping the split on colons means that colons are not accepted
in pathnames of br2-external trees; in practice, this is not a new
restriction, or one that could lift as usign colons in Makefiles are
problematic anyway.
[0] in 20cd497 core: add support for multiple br2-external trees
Reported-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Reported-by: Brandon Maier <Brandon.Maier@collins.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
https://ccache.dev/releasenotes.html#_ccache_4_13_1 Updated license hash due to copyright year bump: ccache/ccache@91a090a Signed-off-by: Bernd Kuhls <bernd@kuhls.net> Signed-off-by: Julien Olivain <ju.o@free.fr>
https://github.com/harfbuzz/harfbuzz/blob/13.1.1/NEWS Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> Signed-off-by: Julien Olivain <ju.o@free.fr>
Backport upstream patches to fix a silent crash in U-Boot on STM32MP135F-DK. Fixes: https://gitlab.com/buildroot.org/buildroot/-/commit/799d184e89bc52de9c1b0e241f60d9827a473128 Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> [Romain: add Fixes link] Signed-off-by: Romain Naour <romain.naour@smile.fr>
Remove incorrect $BINARIES_DIR reference from the symbolic link creation to make a relative path and not an absolute path. Signed-off-by: Neal Frager <neal.frager@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Romain Naour <romain.naour@smile.fr>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )