This new binutils version break the ATF build due to new linker warnings:
ld.bfd: warning: bl2.elf has a LOAD segment with RWX permissions
From [1]
"Users of GNU ld (BPF) from binutils 2.39+ will observe multiple instaces
of a new warning when linking the bl*.elf in the form:
ld.bfd: warning: stm32mp1_helper.o: missing .note.GNU-stack section implies executable stack
ld.bfd: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
ld.bfd: warning: bl2.elf has a LOAD segment with RWX permissions
ld.bfd: warning: bl32.elf has a LOAD segment with RWX permissions
These new warnings are enbaled by default to secure elf binaries:
- https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
- https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=0d38576a34ec64a1b4500c9277a8e9d0f07e6774
"
Bump the ATF custom version to 2.9 for binutils 2.39+ support.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4889436283
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bump the kernel to the latest release of 5.4 kernel series
to fix an issue with gcc 12.
arch/mips/jz4740/setup.c: In function 'plat_mem_setup':
arch/mips/jz4740/setup.c:64:25: error: comparison between two arrays [-Werror=array-compare]
64 | if (__dtb_start != __dtb_end)
| ^~
arch/mips/jz4740/setup.c:64:25: note: use '&__dtb_start[0] != &__dtb_end[0]' to compare the addresses
CC fs/debugfs/file.o
cc1: all warnings being treated as errors
Fixed in v5.4.195:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a60def7568216684f62b117c199429c4a9a89570
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4889436573
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
objtool built by the kernel requires libelf
ldd output/build/linux-6.1.24/tools/objtool/objtool
linux-vdso.so.1
libelf.so.1 => output/host/lib/libelf.so.1
While updating the kernel [1] we forgot to select
BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF to provide Buildroot's host-libelf.
Using host-libelf avoid linking with libelf installed on the host or
failing to build objtool if libelf is not installed.
[1] d45538f2e7
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4889436869https://gitlab.com/buildroot.org/buildroot/-/jobs/4889436872
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 2a5d90a595 (configs/rock5b: Add patches to fix gcc12 warnings)
introduced the kernel patches in an incorrect directory.
Fix that by moving them in the proper location.
Reported-by: Kilian Zinnecker <kilian.zinnecker@mail.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This patch introduces patches for the custom kernel, as it is
currently used for the Radxa Rock 5B. The patches fix two gcc
compiler warnings, which result in a build error, if the kernel
is used with gcc version 12.
Since also the code of custom board drivers for WiFi support is
affected, and no fixes are provided by the vendor, the custom WiFi
support is disabled.
Signed-off-by: Kilian Zinnecker <kilian.zinnecker@mail.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This runtime test was suggested in discussion [1]. It should detect
potential runtime failures such as the one fixed in commit eb74998125
"package/nftables: fix the build of the pyhon bindings".
We need a special kernel, because not all nftables-related options are
enabled in the pre-built one.
[1] https://lists.buildroot.org/pipermail/buildroot/2023-August/672864.html
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This is the follow-up commit to the 4de60e4 which disables
sourcehighlight dependency for the target GDB package.
Do the same for the host variant to be sure that this
won't be picked up from the host system.
Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
nftables provides python bindings; it uses setuptools to install them.
We currently install those bindings by telling the nftables buildsystem,
autotools, to install the python bindings.
However, we do not pass any of the environment variables that are needed
for setuptools packages. When host-python-setuptools is installed before
nftables is built [0], this breaks the system at runtime, as the
bindings are not installed; only the egg is, resulting in runtime errors
like:
# python -c 'import nftables'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'nftables'
Upstream has been doing some changes on their python handling, but it is
not in a released version yet, and we can't backport those changes
either, due to other big changes.
Instead, we split the pyhon bindings to their own package.
For legacy handling, we make that new package default to y, so that
existing (def)config still work. The only novelty is that it can be
disabled now.
Many thanks to Julien for testing and finding the offending dependency,
to James for suggesting the package split, and to Adam for, well,
trigerring the issue in the first place! ;-p
Note: a git bisect of the issue turns up 72 candidates for the breakage,
all around the time we dropped python2 support in early 2022; the last
known-good commit is 55df30f8b1 (package/zfs: drop python2 support)
and the first known-bad commit is 697acda00d (package/pkg-python: drop
python2 host/setuptools support); everything in-between does not
configure (package/python/Config.in.host still sourced but already
removed), or does not build (host-python still in the dependency chain
but already removed), so had to be skipped during the bisect.
[0] This can happen when another python package using setuptools is
built before nftables. However, with PPD, this never happens because
host-python-setuptools is never in the dependency chain of nftables.
Reported-by: Julien Olivain <ju.o@free.fr>
Tested-by: Julien Olivain <ju.o@free.fr>
Suggested-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following security issues:
- CVE-2023-28366: Fix memory leak in broker when clients send multiple QoS 2
messages with the same message ID, but then never respond to the PUBREC
commands.
- CVE-2023-0809: Fix excessive memory being allocated based on malicious
initial packets that are not CONNECT packets.
- CVE-2023-3592: Fix memory leak when clients send v5 CONNECT packets with a
will message that contains invalid property types.
- Broker will now reject Will messages that attempt to publish to $CONTROL/.
- Broker now validates usernames provided in a TLS certificate or TLS-PSK
identity are valid UTF-8.
- Fix potential crash when loading invalid persistence file.
- Library will no longer allow single level wildcard certificates, e.g. *.com
For more details, see the changelog:
https://mosquitto.org/ChangeLog.txt
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The bump to meson 1.2.0 triggers unexpected build failure of the host
packages, because meson changed the way it passes library search paths
when building natively:
59cfbf68e0http://lists.busybox.net/pipermail/buildroot/2023-August/672649.html
As a consequence, the libraries are searched for in the system paths
before being searched in our host-dir, leading to failures when
incompatible libraries are installed in both locations. For example, if
the system has an older version of libglib2 installed, this causes link
failures when one of the glib2 library (e.g. libgio) is linked by path,
but a dependent library (e.g. libgmodule) is linked by name:
/path/to/host/lib/libgio-2.0.so -L /path/to/host/lib/ -lgmodule-2.0
The first is indeed the one we built and installed in host-dir, but the
second is found in the system path; when it is an older (or more
recent?) version than the one we use, the link fails;
/path/to/host/lib/libgio-2.0.so: undefined reference to `g_module_open_full'
Since fixing the issue is not trivial, revert to the previous meson
version that did not exhibit the issue.
This reverts commit d06e610d58.
Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit e3322e2c7 "lsof: add license info" added the package license
info. At that time, lsof was at version 4.85. The package was not
including a dedicated license file. Instead, the license text was
copied in many files (source files, readmes, ...). It was then decided
to use the small source file "dialects/linux/dproto.h".
Recently, lsof added a COPYING license file. See [1]. This commit was
first included in lsof version 4.97.0. We can now use this file.
The license file hash is updated due to formatting changes. As a side
note, the copyright year in source file was 1997 (see [2]), whereas in
the new license file it is 2002. Source files have different copyright
dates, and can be as old as 1994, for example in [3]. The rest of the
license text remains unchanged.
[1] 62dab61cae
[2] https://github.com/lsof-org/lsof/blob/4.98.0/dialects/linux/dproto.h#L9
[3] https://github.com/lsof-org/lsof/blob/4.98.0/arg.c#L7
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Backport an upstream:
"Add -DOPENSSL_API_COMPAT=10100 to the build flags to avoid this and be
flexible with regards to which version of OpenSSL build environment has
to provide"
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4839060472
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Don't specify the ARCH_FLAGS of U-Boot, so both extensions can be
appended to -march when building w/ gcc-12.
Fixes:
- https://gitlab.com/buildroot.org/buildroot/-/jobs/4839059655
Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The compiler-rt project intructs to build out of tree:
https://compiler-rt.llvm.org/
Otherwise, the dependency chain declared in the include/CMakelLists.txt
causes a circular dependency of source files upon themselves:
make[4]: Circular include/sanitizer/allocator_interface.h <- include/sanitizer/allocator_interface.h dependency dropped.
make[4]: Circular include/sanitizer/asan_interface.h <- include/sanitizer/asan_interface.h dependency dropped.
make[4]: Circular include/sanitizer/common_interface_defs.h <- include/sanitizer/common_interface_defs.h dependency dropped.
[--snip 19 other files--]
This is because include/CMakeLists.txt unconctional declares
dependencies in this manner:
set(SANITIZER_HEADERS
sanitizer/allocator_interface.h
sanitizer/asan_interface.h
sanitizer/common_interface_defs.h
[...]
)
set(COMPILER_RT_HEADERS
${SANITIZER_HEADERS}
[...])
set(output_dir ${COMPILER_RT_OUTPUT_DIR}/include)
foreach( f ${COMPILER_RT_HEADERS} )
set( src ${CMAKE_CURRENT_SOURCE_DIR}/${f} )
set( dst ${output_dir}/${f} )
add_custom_command(OUTPUT ${dst}
[...]
)
[...]
endforeach( f )
The froeach() loop creates dependency rules between the files in
output_dir and CMAKE_CURRENT_SOURCE_DIR, without provision for the
case they are both the same directories, thus in-source builds are
not supported.
With the Makefiles backend, this only triggers the above warning
from make, because make arbitrarily breaks circluar dependencies, and
in this case it makes it work. But when we switch to the ninja backend,
this is going to be a hard error.
Anyway, ninja or make, compiler-rt does not support in-source builds.
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
[yann.morin.1998@free.fr: drastically expand commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since it was iontroduced in commit d4ecefa3cc (package/perftest: new
package), perftest was missing the reverse dependency on the kernel
headers version inherited from rdma-core.
In commit 3279d8b9c4 (package/rdma-core: needs NPTL), the dependency
of rdma-core on NTPL was not propagated to its reverse dependencies,
notably perftests.
Fixes:
- http://autobuild.buildroot.net/results/00c/00ce19a1589c6028ee77c333ed9107e2c8c8d6de
- d4ecefa3cc
- 3279d8b9c4
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[yann.morin.1998@free.fr:
- also add misisng headers dependency
- expand commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Previously, gen-bootlin-toolchains did not add a `depends` guard to
limit the available toolchains based on the minimum required GCC version
for the user selected CPU tuning.
Now, the proper BR2_ARCH_NEEDS_GCC_AT_LEAST_X guard will be added based
on the version of GCC provided by the toolchain.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
[yann.morin.1998@free.fr: regenerate the toolchain list]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Previously, it was possible to select an external toolchain that did not
support the GCC arch tuning the user had selected. This is problematic
because it can lead to confusing error messages during builds [0].
Now, external toolchain selections will be filtered to only those that
support the required GCC version specified by the target arch tuning.
Note: this patch does not touch the Bootlin toolchain config file as it
is generated by a script.
Additional note: there is "soft" support for toolchains prior to GCC 4.8
but there are no accompanying BR2_ARCH_NEEDS_GCC_AT_LEAST_X symbols.
Instead of adding those, just use BR2_ARCH_NEEDS_GCC_AT_LEAST_4_8 which
is the minimum GCC version with claimed support [1].
[0]: https://lists.buildroot.org/pipermail/buildroot/2023-August/671877.html
[1]: https://buildroot.org/downloads/manual/manual.html#requirement-mandatory
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following build failure:
>>> toolchain-external-codescape-img-mips 2018.09-02 Copying gdbserver
Could not find gdbserver in external toolchain
Fixes:
- http://autobuild.buildroot.org/results/b0786965e0b249c8168df855682e54cfe95fa0cc
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fix the following build failure:
>>> toolchain-external-codescape-mti-mips 2018.09-02 Copying gdbserver
Could not find gdbserver in external toolchain
Fixes:
- http://autobuild.buildroot.org/results/ead304285a9cf32bf6b9dcc7fc30acece25ec680
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add a custom case to make sure that a random configuration with an empty
configuration file for ubi doesn't fail.
ubinize: error!: no sections found the ini-file "/home/buildroot/autobuild/instance-2/output-1/build/ubinize.cfg"
Fixes:
- http://autobuild.buildroot.org/results/f678c17cc4df06fb2737467e769cd8f72a3ea420
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Use full relative pathes for rootfs and kernel, like in other
readme's.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Urcu does not like -O0 it needs gcc optimizations.
Force -O1 in this case. Inspired by package fwts.
The issue got introduced in commit 2f8f69012e:
before this commit, xfsprogs builds fine at -O0, after this commit, it fails
to build at -O0. As this commit went into 2022.02, the fix needs to be
backported to stable branches.
Fixes:
- http://autobuild.buildroot.net/results/3bd/3bd7de784953ab1fa70bf5572eccd7b10e4a0e17
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gcc 12 added a warning that triggers on access to low addresses. Add a
patch to allow access since this is normal for low level code.
Rebase our existing patch on top. While at it, add also a proper
Upstream tag.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4795673785
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Linux added mnt_id member to struct statx in commit:
fa2fcf4f1df1559a0a4ee0f46915b496cc2ebf60
Linux 5.4.0 was released on 24. November 2019, but it seems this change
never got backported to 5.4.252.
Upstream added a patch to guard the use of the member in commit:
c0136ac0c9
Add the patch to fix an autobuild failure.
Fixes:
- http://autobuild.buildroot.net/results/d50/d502bc9236b577e2470a30ffc39c21579b038a1c
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Compile of e2fsprogs is failing because of gcc bug
111001. Workaround it by forcing the usage of -Os.
Compile fails with:
CC rw_bitmaps.c
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
during RTL pass: sh_treg_combine2
rw_bitmaps.c: In function 'read_bitmaps_range_start':
rw_bitmaps.c:447:1: internal compiler error: Aborted
447 | }
| ^
0x5e7a6f ???
../sysdeps/aarch64/start.S:81
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <http://bugs.buildroot.net/> for instructions.
No need to backport, because gcc 13.2.0 was introduced recently in
Buildroot commit: 3009095ba8
Fixes:
- http://autobuild.buildroot.net/results/fb7/fb7e9c8b02b979b3a75185c0afa4ab0ca654f6f6
- http://autobuild.buildroot.net/results/659/659313b1783db491653bcc85b37da40c7b077225
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
e2fsprogs package fails to build for the SH4 architecture due to a gcc
13.2.0 bug that leads to:
during RTL pass: sh_treg_combine2
rw_bitmaps.c: In function read_bitmaps_range_start:
internal compiler error: Aborted
Let's add gcc bug to avoid to deal with architectures in packages
when a gcc bug arises. Let's instead deal directly with gcc
bug number.
It's been reported upstream:
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=111001
No need to backport as gcc 13.20 was introduced recently in
buildroot.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is a new Buildroot package and this is the first build error
the autobuild servers found. It is not part of any Buildroot release
so no need to backport.
Patch removes dlfcn.h, because it is unused.
Fixes:
- http://autobuild.buildroot.net/results/db3/db301e9f556592828800fa663f2549f430adb58f
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The dependency is not provided by Buildroot, and it can potentially be
found by gdb's build system from the host system, which results in the
following build errors:
../../gdb/source-cache.c:37:10: fatal error: srchilite/sourcehighlight.h: No such file or directory
37 | #include <srchilite/sourcehighlight.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[4]: *** [Makefile:1645: source-cache.o] Error 1
make[4]: *** Waiting for unfinished jobs....
Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
screenfetch requires an "awk" implementation, but upstream would
only use an executable called "awk": pick up upstream patch that
can autodetect awk implementation, so that "mawk" can be used.
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Most of the users use HDMI console on RPi and with increasing popularity
of systemd they face a trouble.
systemd doesn't use /etc/inittab, enable getty@tty1.service instead.
Signed-off-by: Alexey Roslyakov <alexey.roslyakov@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In Buildroot commit cc69dbf8fd
("package/libedit: bump version to 20221030-3.1"), the version of
libedit was bumped from 20210910-3.1 to 20221030-3.1. This broke the
build with uClibc:
./sys.h:96:1: error: unknown type name 'ssize_t'; did you mean 'size_t'?
Header file uses ssize_t so sys/types.h must be included.
This commit adds a patch that fixes this issue.
Fixes:
http://autobuild.buildroot.net/results/439538b23776a58ff81c38754a19ee92c3590a1f
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add patch taken from upstream pull request ([1]) to fix gcc-13.x compile
failure because of a missing csdtint include.
Fixes:
In file included from libserial/SerialStreamBuf.h:36,
from SerialStreamBuf.cpp:34:
./libserial/SerialPortConstants.h:93:37: error: ‘uint8_t’ was not declared in this scope
93 | using DataBuffer = std::vector<uint8_t> ;
| ^~~~~~~
[1] https://github.com/crayzeewulf/libserial/pull/186
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 503252d8b0 (boot/lpc32xxcdl: remove package) forgot to remove
the special handling in genrandconfig. Since the package no longer
exists, we don't need to special-case its symbol anymore, so drop it
now.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This package has dubious licensing conditions (not even documented in
the .mk file), and is a bootloader for very old platforms. The
defconfigs making use of it have been removed in Buildroot in 2014, in
commit c6a410964b ("configs: remove
lpc32xx defconfigs"), so let's get rid of the package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
[yann.morin.1998@free.fr: remove reference in test]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
xlib_libXpresent is needed with x11 to avoid the following build failure
raised since bump to version 0.35.1 in commit
61ba55e9cc and
3d459832a8:
Checking for X11: no ('x11 >= 1.0.0 xscrnsaver >= 1.0.0 xext >= 1.0.0 xinerama >= 1.0.0 xpresent >= 1.0.0 xrandr >= 1.2.0' not found)
You manually enabled the feature 'x11', but the autodetection check failed.
Fixes:
- http://autobuild.buildroot.org/results/1aace6210ba966bb4979d935c08507b2a34e0460
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Needed for mpv since version 0.35.0:
3d459832a8
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Thomas: improved thanks to feedback from a similar patch submitted by
Bernd Kuhls.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Until now, the Python build system was building a _dbm.cpython-*.so
native module when BR2_PACKAGE_PYTHON3_BERKELEYDB was enabled, but
since the bump of Python to 3.11.x, it was no longer building this
native module.
Investigation this, we found out that Python 3.11 changed how libdb
was detected [1] and that check now fails:
quoting configure log:
checking for libdb... no
quoting python config.log:
conftest.c:(.text.startup+0x8): undefined reference to `__db_ndbm_open'
However, in fact it turns that this problem is not new in Python
3.11. In Python 3.10, the build system was always producing the native
module, but it was in fact not working at runtime:
>>> from _dbm import *
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: /usr/lib/python3.10/lib-dynload/_dbm.cpython-310-arm-linux-gnueabihf.so: undefined symbol: __db_ndbm_delete
It was not really visible because when one does "import dbm", it
actually tries several "backends", including ndbm (which relies on
_dbm above), and if it doesn't work, it falls back silently on a pure
Python implementation.
So the issue was never noticed, but has already been there,
potentially forever.
In order for this _dbm native module to be built (Python >= 3.11) or
to work (Python < 3.11), the BerkeleyDB library need to be built with
its so-called "dbm" interface, which we do by selecting select
BR2_PACKAGE_BERKELEYDB_DBM.
And now:
>>> import _dbm
>>>
[1] d2340ef257/configure.ac (L4002)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Thomas: did more research to have a better explanation of what is
happening, and realize the problem is not related to Python 3.11]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Berkeley DB support in python depends on dbm, when missing python fails
to detect libdb:
d2340ef257/configure.ac (L4002)
quoting python configure log:
checking for libdb... no
quoting python config.log:
conftest.c:(.text.startup+0x8): undefined reference to `__db_ndbm_open'
This patch provides a configure option for the historic dbm interface
to be used by the python package.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
