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>
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>
While it's not strictly necessary to update go-bootstrap-stage2, we can
continue to update the package to the latest 1.19.x until Go 1.19.x is
discontinued, at which point we can leave it at the final 1.19.x
version.
This package is only used when bootstrapping host-go.
go1.19.11 includes a security fix to the net/http package, as well as
bug fixes to cgo, the cover tool, the go command, the runtime, and the
go/printer package.
https://go.dev/doc/devel/release#go1.19.minor
Signed-off-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The m68k Linux kernel build is broken with binutils >= 2.41 with:
arch/m68k/fpsp040/skeleton.S: Assembler messages:
arch/m68k/fpsp040/skeleton.S:502: Error: junk at end of line, first unrecognized character is `#'
arch/m68k/fpsp040/skeleton.S:508: Error: junk at end of line, first unrecognized character is `#'
This commit adds a backport from the upstream Linux kernel which fixes
this issue. Many thanks to Romain Naour for the issue investigation
and the identification of the kernel commit fixing this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In upstream commit e71ecc8771a4f13bc6046438ab0845944831b9a6 ("build:
Remove deprecated -Diconv option"), merged since glib 2.75.1, the
meson -Diconv option was removed.
In Buildroot, this means that the build of libglib2 has been broken
since commit 3f9622fe3d, which bumped
libglib2 from 2.72.3 to 2.76.1 for configurations that have libiconv
enabled, causing this build failure:
../output-1/build/libglib2-2.76.1/meson.build:1:0: ERROR: Unknown options: "iconv"
iconv is now automatically detected by Meson machinery, and so the
option was considered as no longer being needed. This commit fixes
that by dropping the useless -Diconv=external.
Another related change done is remove the double addition of libiconv
into the <pkg>_DEPENDENCIES variable: libiconv can only be enabled
when BR2_ENABLE_LOCALE is disabled, and libglib2/Config.in selects
BR2_PACKAGE_LIBICONV when !BR2_ENABLE_LOCALE. So testing
BR2_ENABLE_LOCALE!=y and BR2_PACKAGE_LIBICONV=y is exactly the same
thing, causing libiconv to be added twice to the dependencies.
Fixes:
http://autobuild.buildroot.net/results/d2da03f7558f3b6ee59c813bb64115702e52704c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libheif package fails to build for the M68K architecture due to a binutils
bug that leads to:
Internal error in emit_expr_encoded at dw2gencfi.c:215
Let's add binutils bug to avoid to deal with architectures in packages
when a binutils bug arises. Let's instead deal directly with binutils
bug number.
It's been reported upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=30730
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- improve 8ULP support (rev A1)
- add mmc user fastboot support
- add fastboot partconf support
- add nitrogen8mp smarc support
Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The release tarball of check 0.15.2 lacks a source file, causing a
build failure, as reported at
https://github.com/libcheck/check/issues/303. This failures happens
when thread support is not available, as the file missing is getting
compiled in when thread support is not there:
if(NOT HAVE_PTHREAD)
target_sources(check PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/../lib/pthread_mutex.c)
target_sources(checkShared PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/../lib/pthread_mutex.c)
endif()
This issue started appearing when we moved from the autotools build
system to the CMake build system in commit
6dfc789f4f. One might wonder why
changing the build system can cause this kind of issue: the file was
in fact already missing. Turns out that the missing file is never used
with the autotools build system: this file provides some Win32
compatibility layer for pthread functions, so the autotools build
system never compiled this file as the autotools build system was only
used on Unix platforms. With CMake it now gets compiled to support
Windows platform. But on Linux, the entire contents of the file is
ignored as it is within a HAVE_WIN32_INIT_ONCE ifdef...endif. Still,
with the file missing, the build fails.
Until upstream publishes a new release with a complete tarball, switch
to fetching the Github-generated tarball, which does contain the
missing file.
Fixes:
http://autobuild.buildroot.net/results/b1087e9a67ff0382632b73f280fabe92cd863593/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
