As the comment in package/perl/perl.mk instructs, bumping the perl
version must be propagated to utils/scancpan as well.
However, commit 7c1ef8129f (package/perl: bump to version 5.34.0)
forgot to do so.
Fixes: 7c1ef8129f
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
igh-ethercat comes with a small number of patched Linux kernel network
drivers, which aim at replacing the ones available in upstream Linux
kernel. All those drivers are provided only for specific kernel
releases. For example:
r8169-2.6.24-ethercat.c
r8169-2.6.24-orig.c
r8169-2.6.27-ethercat.c
r8169-2.6.27-orig.c
r8169-2.6.28-ethercat.c
r8169-2.6.28-orig.c
r8169-2.6.29-ethercat.c
r8169-2.6.29-orig.c
r8169-2.6.31-ethercat.c
r8169-2.6.31-orig.c
r8169-2.6.32-ethercat.c
r8169-2.6.32-orig.c
r8169-2.6.33-ethercat.c
r8169-2.6.33-orig.c
r8169-2.6.35-ethercat.c
r8169-2.6.35-orig.c
r8169-2.6.36-ethercat.c
r8169-2.6.36-orig.c
r8169-2.6.37-ethercat.c
r8169-2.6.37-orig.c
r8169-3.10-ethercat.c
r8169-3.10-orig.c
r8169-3.12-ethercat.c
r8169-3.12-orig.c
r8169-3.14-ethercat.c
r8169-3.14-orig.c
r8169-3.16-ethercat.c
r8169-3.16-orig.c
r8169-3.2-ethercat.c
r8169-3.2-orig.c
r8169-3.4-ethercat.c
r8169-3.4-orig.c
r8169-3.6-ethercat.c
r8169-3.6-orig.c
r8169-3.8-ethercat.c
r8169-3.8-orig.c
r8169-4.4-ethercat.c
r8169-4.4-orig.c
Obviously, this doesn't play well with the random configuration
testing done by utils/genrandconfig. This commit avoids this issue by
making sure we never build any of those drivers as part of the
genrandconfig generated configurations.
Fixes:
http://autobuild.buildroot.net/results/07b7475d780c067d99ee5618a5fd2bb024a5b4e7/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When BR2_XTENSA_CUSTOM=y is used with the internal toolchain, an
overlay file is mandatory, which genrandconfig can't provide. So we
simply disallow such configurations.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In the internal toolchain backend, we have a choice..endchoice block
to allow the user to select the C library, between glibc, uClibc and
musl.
However, there are situations were no C library at all is
supported. In this case, the choice does not appear, and does not
allow to see the Config.in comments that are within the
choice..endchoice block and that may explain why no C library is
available.
For example, on RISC-V 32-bit, the only C library supported is glibc,
and the minimum kernel header version required by glibc on this
architecture is 5.4.0. In a future commit, we are going to add this
dependency on glibc (to fix build issues on configurations that have
headers < 5.4.0). But since glibc is the only supported C library on
RISC-V 32-bit, it means that the choice..endchoice for the C library
contains no entry, preventing from seeing the Config.in comment.
To address this issue, this commit adds a "dummy"
BR2_TOOLCHAIN_BUILDROOT_NONE option that shows up in the
choice..endchoice only when no C library is available. Thanks to this,
the choice..endchoice is never empty, and the Config.in comments can
be seen.
If the user keeps BR2_TOOLCHAIN_BUILDROOT_NONE selected, then the
build will anyway abort early because package/Makefile.in has a check
to verify that a C library is selected, and aborts the build if not.
Some could say that the problem should be resolved by instead
preventing the selection of headers < 5.4.0 on RISC-V 32-bit, but that
is difficult to do as the user can choose a custom header version, or
simply specific that (s)he wants to use the headers of the kernel
being built. In those situations, it's difficult to prevent selecting
headers < 5.4.0.
Prevent random configurations from triggering a build failure in our
autobuilders, by excluding that symbol from accepted configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: update genrandconfig]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
libopenssl needs atomic or the build will fail (e.g. on sparcv8 without
libatomic):
${LDCMD:-/nvmedata/autobuild/instance-7/output-1/host/bin/sparc-buildroot-linux-uclibc-gcc} -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O0 -g2 -g2 -L. \
-o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_client.o apps/s_server.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/storeutl.o apps/ts.o apps/verify.o apps/version.o apps/x509.o \
apps/libapps.a -lssl -lcrypto -ldl
/nvmedata/autobuild/instance-7/output-1/host/lib/gcc/sparc-buildroot-linux-uclibc/10.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: ./libssl.so: undefined reference to `__atomic_fetch_sub_4'
It should be noted that openssl3 has added OPENSSL_DEV_NO_ATOMICS but
"this is intended for internal development only, to check the
refcounting is properly coded. It should never become a configuration
option, hence the name of the macro.":
https://github.com/openssl/openssl/commit/503d4745a115b82db01c1fb22baaddb153d27cdb
Atomics are not available in Buildroot if:
- architecture is 32 bit and something other than ARM or xtensa, and
- GCC < 4.8 or no threads or FLAT.
The nothreads case can theoretically happen in many different
situations, but in practice nobody disables threads. So the only
interesting case is the FLAT case. Since ARM and RISC-V 64 both have
atomics intrinsics, that leaves just m68k NOMMU as FLAT. So this is
truly a corner case.
The proper solution would be to patch GCC to also provide libatomic in
those cases.
- For nothreads, atomics are in fact not needed, so libatomic can simply
be implemented as stubs.
- For FLAT, it's probably just a matter of having a match to uclinux in
libatomic/configure.tgt.
Again, though, this happens only in such niche cases that it's not worth
working on it.
Fixes:
- http://autobuild.buildroot.org/results/bce526d538f43a541fdfbc0c9b4a7cecebbbc539
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
From flake8:
utils/genrandconfig:429:21: E703 statement ends with a semicolon
1 E703 statement ends with a semicolon
Fixes: d3e029575c
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
In case of an unexpected error, we currently only print the exception as
an str(). For example, the recent issue with the glibc version check
only reported:
TypeError: cannot use a string pattern on a bytes-like object
That does not help in fixing the issue; the exception text is also not
usually very user-friendly either anyway.
We change the reporting to print the traceback, which in the glibc
version check mentioned above, the error is reported as:
Traceback (most recent call last):
File "./utils/genrandconfig", line 740, in <module>
ret = gen_config(args)
File "./utils/genrandconfig", line 676, in gen_config
if not is_toolchain_usable(configfile, toolchainconfig):
File "./utils/genrandconfig", line 186, in is_toolchain_usable
if StrictVersion('2.14') > StrictVersion(glibc_version):
File "/usr/lib/python3.8/distutils/version.py", line 40, in __init__
self.parse(vstring)
File "/usr/lib/python3.8/distutils/version.py", line 135, in parse
match = self.version_re.match(vstring)
TypeError: cannot use a string pattern on a bytes-like object
With this, the error is much easier to pinpoint (it's the last one that
is not in a system module).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Unless explicitly told otherwise, subprocess.check_output() returns
bytes objects [0].
When we try to check the C library version (to check the Linaro
toolchain is usable), genrandconfig currently fails with:
TypeError: cannot use a string pattern on a bytes-like object
So, as suggested in the python documentation, decocde() the output of
subprocess.check_output() before we can use it.
[0] https://docs.python.org/3/library/subprocess.html#subprocess.check_output
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
We extend the modules search path to be able to load the package
metadata. Currently, it is only restored when loading those
succeeded, not when it failed.
Restore it to its previous state also in case of error, to avoid
leaking the path further.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit "45aabcddc5 utils/get-developers: really make it callable from
elsewhere than the toplevel directory" had a unforeseen side-effect:
the fact that check-developers with no arguments used to validate the
syntax of the DEVELOPERS no longer works. Indeed, the
parse_developers() call was moved *after* the check that verifies if
at least one action is passed. Due to this, the check-DEVELOPERS
verification in Gitlab CI, which invokes get-developers without
argument to validate the DEVELOPERS file... no longer does anything
useful.
In order to fix this, we introduce an explicit action in
get-developers to request the validation of the DEVELOPERS file. The
implementation is trivial, as the validation is already done by
calling parse_developers(), but at least now we have an action that
does "nothing", except execute until the validation is done.
This is also much more explicit than "invoke get-developers without
arguments to just do validation".
The initial investigation of the issue was done by Ricardo Martincoski
<ricardo.martincoski@gmail.com> and reported at
https://patchwork.ozlabs.org/project/buildroot/patch/20220528014832.289907-1-ricardo.martincoski@gmail.com/,
but we have chosen to introduce a separate -v option rather than
making the validation part of the existing -c action, which serves a
different purpose.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Yann E. MORIN
Peter Seiderer
Fabrice Fontaine
Yegor Yefremov
Thomas Petazzoni
Luca Ceresoli
Arnout Vandecappelle
James Hilliard
Jesse Taube
Ricardo Martincoski