There is currently no version of gdbserver for or1k. Until this
is implemented we will prevent both the direct and indirect
selection of gdbserver for or1k builds. In practice this means
that 'cross gdb for the host' cannot be selected and that
'full debugger' must be automatically selected for the gdb target
package.
This partially reverts commit 991b7b990a
which claimed that gdbserver for or1k was already supported before
version 8.3. That is not true - the commit that adds gdbserver support
for or1k [1] was only merged for version 12.1, which hasn't been
integrated in Buildroot yet.
Without that support, the build of gdbserver fails with
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-musl/11.2.0/../../../../or1k-buildroot-linux-musl/bin/ld: server.o: in function `main':
server.cc:(.text.startup+0x6dc): undefined reference to `initialize_low()'
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-musl/11.2.0/../../../../or1k-buildroot-linux-musl/bin/ld: remote-utils.o: in function `prepare_resume_reply(char*, ptid_t, target_waitstatus*)':
remote-utils.cc:(.text+0x28a8): undefined reference to `using_threads'
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-musl/11.2.0/../../../../or1k-buildroot-linux-musl/bin/ld: remote-utils.cc:(.text+0x28b0): undefined reference to `using_threads'
Fixes: http://autobuild.buildroot.net/results/b3c/b3c0df53d09d9facaf0c3c2bc4529f9fcf7737ee
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4933265c3f71b9134363d0c05f09542d5cc677f4
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Stafford Horne <shorne@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Commit [1] enabled glibc on or1k since it's now supported but it
requires a toolchain with linux-headers >= 5.4.
From [2]:
"Here we define the minumum linux kernel version at 5.4.0, as that is the
long term support version where 32-bit architectures start to support
64-bit time API's. The OpenRISC kernel had some bugs up until version 5.8
which caused issues with glibc fork/clone, they have been backported to
5.4 but not previous versions."
Fixes:
checking installed Linux kernel header files... 3.2.0 or later
checking for kernel header at least 5.4.0... too old!
configure: error: *** The available kernel headers are older than the requested
https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/2875256686
[1] 68d0aede59
[2] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0c3c62ca7d9ff3bdacdd13e636bc858101e3e288
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
openssl is an optional dependency since version 1.5.13 and
ee1cfe3bf9
which must be handled through pkg-config to avoid static build failure
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
While building host-rust with a musl based toolchain without C++ compiler,
the build fail since libunwind bundled in rust sources needs a C++ compiler.
cargo:warning=i686-buildroot-linux-musl-gcc.br_real: error: [...]/host-rust-1.62.0/src/llvm-project/libunwind/src/Unwind-EHABI.cpp: C++ compiler not installed on this system
Note: the issues can't be reproduced with a glibc based toolchain
without C++ probaly due to extra steps required to support musl libc.
We could add the C++ dependency direclty to host-rustc but it would
requires adding the C++ reverse dependencies to all rust packages.
Instread, we add the C++ dependency to BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS
only when a musl toolchain is used. So we can still install a prebuilt
rust compiler but without the rust standard library (rust-std).
Usually we should not add toolchain dependencies in a _ARCH_SUPPORTS option but
BR2_PACKAGE_HOST_RUSTC_TARGET_TIER... options contains already some
BR2_TOOLCHAIN_USES_GLIBC or BR2_TOOLCHAIN_USES_MUSL.
Fixes:
http://autobuild.buildroot.org/results/636/636fb39c8f1b8c05e4ca451ac506cd63c7166d82
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Nicolas Tran <nicolas.tran@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
fixes:
- Fixed comparison of maps in Python.
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The COPYRIGHT file hash has changed due to:
- Copyright (c) 1991, 1999, 2002, 2005-2018,2019 John E. Davis
+ Copyright (c) 1991, 1999, 2002, 2005-2021, 2022 John E. Davis
Signed-off-by: Sven Oliver Moll <svolli@svolli.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The changelog is available here:
https://github.com/analogdevicesinc/libiio/releases/tag/v0.24
Remove the 0001 patch as it is included in the v0.24 version.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To report usable tracebacks, pyc files embed the path of the original py
files, so that users can more easily try and debug the reported issue.
We generate the pyc files by calling the python3-supplied compileall
script, to scan the directory where python modules are installed. Since
this is done on the build machine, we tell compileall.py to strip away
the TARGET_DIR prefix, as that has no meaning at runtime.
However, compileall.py forgets [0] to keep a leading / in the front of
the paths, thus generating non-rooted paths., e.g.:
/path/buildroot.ouput/targt/usr/lib/python3.10/argparse.py
gets embedded as:
usr/lib/python3.10/argparse.py
This is a bit confusing but, as far as we could see, should be mostly be
used for display purposes in tracebacks, and does not seem to impact
actual functionality.
We fix that by instructing compileall.py that the embedded paths should
be rooted to / which generates proper paths in tracebacks.
And alternate solution would be to swith gears, and tell compileall.py
exactly the resulting runtime "base" directory, which replaces the
stripping and prefixing; i.e. it's either:
-s $(TARGET_DIR) -p /
or
-d /usr/lib/python$(PYTHON3_MAJOR_VERSION)
We choose to keep the first solution, because that is semantically what
we really want to do: to strip the leading build-time path, rather than
to force anything.
Note: the python test-suite was executed with both solutions (in a
pyc-only setup), and the results were exactly the same; so in practice,
-d or -s+-p yield the same results.
Many thanks go to Vincent for reporting the issue and suggesting the
solutions.
[0] Not sure whether this is a bug or a feature...
Reported-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This reverts commit 0be1c3e921.
The actual issue is more complex. The problem purportedly fixed was not
caused by a missing libupsclient (it was present), but by a missing type
definition for time_t (on a musl toolchain).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Disable libupsclient to avoid the following build failure if
libupsclient is installed on host:
src/nut.c:40:2: error: #error "Unable to determine the UPS connection type."
40 | #error "Unable to determine the UPS connection type."
| ^~~~~
src/nut.c:46:3: error: unknown type name 'collectd_upsconn_t'
46 | collectd_upsconn_t *conn;
| ^~~~~~~~~~~~~~~~~~
libupsclient is an optional dependency of nut plugin since version
5.10.0 and
bc2d94024d
Fixes:
- http://autobuild.buildroot.org/results/22b758097e8fb72c68e41329cbc7abc748d81ca6
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Add a new option to have MbedTLS builds that support DTLS-SRTP.
We can only enable the support, it's disabled by default.
Signed-off-by: Dmitry Ilyin <dima@doty.ru>
[yann.morin.1998@free.fr:
- rename variable
- fix variable name in .mk
- drop unnecessary ref to AWS library
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The rule is one-item per line in multi-line assignments, starting with
the first item on its own line too?
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
poco 1.12.0 updated its pcre depencency to pcre2, see:
https://github.com/pocoproject/poco/blob/poco-1.12.2-release/CHANGELOG#L37
The Kconfig selection and dependencies are updated accordingly. This
commit also reorder those Kconfig options alphabetically.
This commit adds an upstream patch to fix compilation failure with
oracle-mysql. See:
3884c734c2
This commit also adds "-latomic" to ldflags at configuration time, if
the toolchain has it. This is required for some architecture: without
this, compilation with bootlin-riscv64-glibc toolchain (for example)
fails at link time with undefined reference to '__atomic_exchange_1'.
The --ldflags option was introduced in 1.12.0 (Thanks Fabrice). See:
https://github.com/pocoproject/poco/pull/3545
For the full Poco change log since 1.11.12, see:
https://github.com/pocoproject/poco/blob/poco-1.12.2-release/CHANGELOG
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This is a bug-fix release, fixing a $edit_headers bug on MacOS, along
with a few other small bugs. It also tightens the $query_command parser
to accept a single tab between fields, and changes $pager to accept a %s
expando.
https://gitlab.com/muttmua/mutt/-/blob/mutt-2-2-7-rel/ChangeLog
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The script "utils/check-package" checks that patch email prefix are
not be numbered. See:
https://git.buildroot.org/buildroot/tree/utils/checkpackagelib/lib_patch.py?h=2022.08-rc1#n42
The error message recommends to generate patches to be included in
Buildroot with the command 'git format-patch -N'.
The patch policy section in the Buildroot manual does mention that.
This commit adds a note about that requirement.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Disable -Werror to avoid the following build failure:
In file included from hash.c:7:
xxhash.h:2667:5: error: #warning is a GCC extension [-Werror]
2667 | # warning "XXH3 is highly inefficient without ARM or Thumb-2."
| ^~~~~~~
xxhash.h:2667:5: error: #warning "XXH3 is highly inefficient without ARM or Thumb-2." [-Werror=cpp]
Fixes:
- http://autobuild.buildroot.org/results/3124bae73c207f1a118e57e41e222ef464ccb297
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Add license hashes to the hash file and add the information into the
makefile.
Signed-off-by: Jesse Van Gavere <jesseevg@gmail.com>
[Arnout: use correct file names and hashes]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Fixes flake8 errors:
support/scripts/pkg-stats:1013:133: E501 line too long (164 > 132 characters)
support/scripts/pkg-stats:1018:36: F541 f-string is missing placeholders
support/scripts/pkg-stats:1110:199: E261 at least two spaces before inline comment
For the first and the last one, we chose to split the long lines rather
than adding noqa: 501. Indeed, the long lines make it very unreadable,
and there are relatively natural places where the line can be broken.
Also split a line just below the second one in a similar way.
The f-string on 1018 doesn't need to be an f-string.
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Fix the following build failure:
In file included from libavcodec/ppc/audiodsp.c:31:
libavcodec/ppc/audiodsp.c: In function 'scalarproduct_int16_altivec':
./libavutil/ppc/util_altivec.h:123:5: error: implicit declaration of function 'vec_vsx_ld'; did you mean 'vec_vslh'? [-Werror=implicit-function-declaration]
123 | vec_vsx_ld(offset, b)
| ^~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/b772d285f978ff9bc3b07872d009633c943f20b1
VSX is indeed an extension to AltiVec, so havinf VSX implies having
AltiVec [0], so we can condition he altivec support on LE ,on VSX being
available.
To be noted, however, is that ffmpeg has a configre switch dedicated to
VSX: --enable-vsx. We do not use it add support for that here, as we are
just fixing the AltiVec support. Adding VSX configure flag is left as an
excercise for a future feature addition.
[0] https://en.wikipedia.org/wiki/AltiVec#VSX_(Vector_Scalar_Extension)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- add comment in .mk
- exend commit log to explain VSX implies AltiVec
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This new version includes many improvements. Release notes:
https://wpewebkit.org/release/cog-0.14.0.html
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
slirp4netns is for user-mode networking for unprivileged network
namespace.
Signed-off-by: Raphael Pavlidis <raphael.pavlidis@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
tools needs C++ since the addition of the package in commit
27ad470d7d resulting in the following
build failure:
no -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I../include -I../master -Wall -DREV=`if test -s ../revision; then cat ../revision; else hg id -i .. 2>/dev/null || echo "unknown"; fi` -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Ofast -g0 -c -o ethercat-Command.o `test -f 'Command.cpp' || echo './'`Command.cpp
/bin/bash: line 1: no: command not found
Fixes:
- http://autobuild.buildroot.org/results/89d096006839f32a3d03786e69e51ec3c5ea70f6
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: move it before package's options]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix CVE-2022-2652: Depending on the way the format strings in the card
label are crafted it's possible to leak kernel stack memory. There is
also the possibility for DoS due to the v4l2loopback kernel module
crashing when providing the card label on request (reproduce e.g. with
many %s modifiers in a row).
https://github.com/umlaeute/v4l2loopback/blob/v0.12.7/ChangeLog
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
