rockchip-mali pre-built libraries needs C++ since the addition of the
package in commit 97c74a73e5:
readelf -a output/build/rockchip-mali-721653b5b3b525a4f80d15aa7e2f9df7b7e60427/lib/aarch64-linux-gnu/libmali-bifrost-g31-rxp0-gbm.so|grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libdrm.so.2]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
While at it, add a comment when dependencies are not met
Fixes:
- No autobuilder failures (yet), found when debugging an issue with
rockchip-mali and glslsandbox-player
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
wayland-protocols is an optional dependency which is enabled by default
resulting in the following wayland build failure since the addition of
the package in commit f201ca9d0d:
checking for wayland_client... yes
checking for wayland_egl... yes
configure: Wayland EGL support enabled
checking for wayland_protocols... no
configure: error: Package requirements (wayland-protocols >= 1.12) were not met:
Package 'wayland-protocols', required by 'virtual:world', not found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables wayland_protocols_CFLAGS
and wayland_protocols_LIBS to avoid the need to call pkg-config.
Fixes:
- http://autobuild.buildroot.org/results/865af860f9e52fe5311bb0c6a246ff871ae5a989
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2023-23931: cryptography is a package designed to expose
cryptographic primitives and recipes to Python developers. In affected
versions `Cipher.update_into` would accept Python objects which
implement the buffer protocol, but provide only immutable buffers. This
would allow immutable objects (such as `bytes`) to be mutated, thus
violating fundamental rules of Python and resulting in corrupted output.
This now correctly raises an exception. This issue has been present
since `update_into` was originally introduced in cryptography 1.8.
https://github.com/pyca/cryptography/security/advisories/GHSA-w7pp-m8wf-vj6rhttps://cryptography.io/en/latest/changelog/#v39-0-1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In GNU Less before 609, crafted data can result in "less -R" not
filtering ANSI escape sequences sent to the terminal.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Shyam's email address at Savoir Faire Linux is bouncing, so drop they
from the DEVELOPERS file.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gnupg2 uses the libgpg-error library. The libgpg-error library has a
long plan to be renamed to "gpgrt" (see [1]). For the transition, it
provides two configuration scripts "gpg-error-config" (the old,
original one, kept for compatibility) and "gpgrt-config" (which is
meant to be the replacement). When both are detected, "gpgrt-config"
should be preferred.
gnupg2 configure script searches for "gpg-error-config" in the path
provided to --with-libgpg-error-prefix=PFX (more specifically, in
"PFX/bin").
The logic to find "gpgrt-config" is different: it is searched in
paths "$prefix/bin:$PATH". See [2]. On Buildroot, autotools target
packages are configured with "--prefix=/usr", which makes the
configure script to search in the host "/usr/bin".
In some host environment providing such a "/usr/bin/gpgrt-config"
script of an older version, host compilation flags are incorrectly
added for the target, which leads to compilation failures.
The issue can be reproduced in a Buildroot Docker image from [3] in
which the libgpg-error-dev package is added. When tested, the
libgpg-error-dev package was at version 1.38.
In that configuration, gnupg2 configure will output the message:
checking for gpgrt-config... /usr/bin/gpgrt-config
and the compilation fails with a message:
aarch64-buildroot-linux-gnu-gcc: ERROR: unsafe header/library path used in cross-compilation: '-I/usr/include'
Note: it was observed that in some other configurations in which the
host /usr/bin/gpgrt-config was from libgpg-error version 1.46, the
host script was redirecting correctly in the buildroot sysroot.
Since gnupg2 searches for "gpgrt-config" with a
"AC_PATH_PROG(GPGRT_CONFIG, ...)" macro, this patch fixes this
issue by simply forcing the script path in the GPGRT_CONFIG
environment variable.
See also [4] which discussed the "gpgrt-config" search logic.
Fixes:
- http://autobuild.buildroot.net/results/423c3ce7317c181e9f2e4a49b76ee9d26167375c/
(and many others)
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=README;h=e0b9f16445a96942af0839bcdb9a0b0f8cf31380;hb=885a287a57cf060b4c5b441822c09d23b8dee2bd#l29
[2] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=m4/gpg-error.m4;h=a975e53d07d1b743f51d8aa1767cd8e0d71b4071;hb=c0556edb80518720b0d884251685fe008c8f0429#l68
[3] https://git.buildroot.org/buildroot/tree/support/docker/Dockerfile?id=b6085c00d0feece6f3ba635e7847ea653bc5fac3
[4] https://dev.gnupg.org/T5365
Reported-by: Bagas Sanjaya <bagasdotme@gmail.com>
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The new option enables the XWayland support, so X11 application can be
running on a wlroots based compositor. Also, do not enable the XWayland
support if the X11 backend is active, as it is unrelated to it.
Signed-off-by: Raphael Pavlidis <raphael.pavlidis@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If the XWayland support is enabled then build the corresponding XServer.
Signed-off-by: Raphael Pavlidis <raphael.pavlidis@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
XServer to run X clients under wayland
This XServer is required to run the X clients under Wayland compositor,
for example weston or wlroots based compositors.
Signed-off-by: Raphael Pavlidis <raphael.pavlidis@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure with libexecinfo raised since commit
d649bcd380:
/home/autobuild/autobuild/instance-9/output-1/host/lib/gcc/mips-buildroot-linux-musl/10.4.0/../../../../mips-buildroot-linux-musl/bin/ld: ../lib/monkey/library/libmonkey.a(mk_utils.c.o): in function `mk_utils_stacktrace':
mk_utils.c:(.text+0x1578): undefined reference to `backtrace'
Fixes:
- http://autobuild.buildroot.org/results/63a6ba9104dfddbd7f6a7debadc0c6ef6e3a21f5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add libexecinfo optional dependency as upstream rejected the patch to
add --with-execinfo=no
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
dmalloc directly calls into $(LD) to generate a shared library our of
the static one.
To detect what command it should run, ./configure tries various
incantations of ld with various command line options until one does not
fail. One of those is (basically):
$(LD) --whole-archive -o contest.o.t contest.a
This makes ./configure conclude what the command to link a shared
library in the Makefile should be, and thus stores that in a variable:
shlinkargs='$(LD) --whole-archive -o $@'
... which is then AC_SUBST()ed into Makefile.in with a rule like:
$(SHLIB): $(LIBRARY)
@shlinkargs@ $(LIRARY)
which once substiuted, gives:
$(SHLIB): $(LIBRARY)
$(LD) --whole-archive -o $@ $(LIRARY)
However, when SSP is enabled, the __stack_chk_fail_local and co symbols
are provided by additional libraries or object files, and that is the
responsibility of gcc to pass those when linking. But as dmalloc
directly calls ld, it misses those.
Changing dmalloc to use $(CC) is not trivial, however.
First, we can't pass LD=$(TARGET_CC), otherwise the whole package
explodes [0]: indeed --whole-archive is unknown to gcc, so it must be
passed as -Wl,--whole archive instead. So we'd need to add a new test
that uses $(CC), like so:
$(CC) -Wl,--whole-archive -o contest.o.t contest.a
However, in that case, gcc does pass additional libs/objs (like, for
eample, the SSP ones) to the linker. But then those are also included
in the whole-archive section. This causes the linker to add all the
symbols form those libs/objs, even those not needed for SSP; on some
archs, like PPC, that may require floating point symbols (__muldiv3 et
al.) which are in another library, and thus the linker can't find them.
The proper solution wouild be to add -Wl,--no-whole-archive, but that
would have to be added _after_ the library we want to link, i.e.e we
should be able to evntually run:
$(CC) -Wl,--whole-archive -o $@ $(LIRARY) -Wl,--no-whole-archive
That would require that we introduce a new variable that is added
_after_ the $(LIBRARY), e.g. @shlinkargs_post@ or so...
This is a bigger endeavour than we want to pursue...
Since dmalloc is a debugging utility, it is not supposed to go into
production builds, and during debugging, it would not be surprising that
it needs to poke around arrays to debug them.
So, we go the easier route: disable SSP altogether.
[0] with lots of nice colors, but that's not the point, is it?
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Our dmalloc packaging is very old and carries historical baggage and
idiosyncracies that we have long stopped doing in the rest ofthe code
base.
Drop our post-patch hooks that seds the configure and Makefile.in files,
and add patches (that could be upstreamed one day).
We provide the results in the environment, like would be done with
actual autoconf cache variables (ac_cv_*).
Note: those are the result of cleaning up for further patches that did
not manifest because it was too complex to add proper SSP support to
dmalloc (instead, we're going to forcibly disable it in the following
commit).
Note-2: those patches have not been submitted upstream, as it's mostly
dead: even though there's been some commit activities recently-ish, there
has been no review or comments or the many PR pending for many years
now.
Note-3: we patch both configure and configure.ac, rather than
autoreconf, for two reasons: 1. the both are in the upstream git tree,
so submitting these patches would require patching both, and 2. dmalloc
does not autoreconf nicely out of the box, and it was deemed too much
hassle to fix that in addition.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
