This bump will fix the following build failure raised since bump of
python3 to version 3.10.1 in commit
25b1fc2898:
Please use python3.9 or python3.8 or python3.7 or python3.6 or python3.5 or python2.7.
/usr/bin/python3.7 ./configure
/usr/bin/python3.5 ./configure
/home/peko/autobuild/instance-1/output-1/host/bin/python2.7 ./configure
Node.js configure: Found Python 3.10.1...
https://github.com/nodejs/node/releases/tag/v14.18.2
Fixes:
- http://autobuild.buildroot.org/results/9e2ebb9c3681ec0485eaa042fa838c8ee62f649b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Tested-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following build failure raised since the addition of the package
in commit eea8ba446c:
execinfo.c:32:10: fatal error: dlfcn.h: No such file or directory
32 | #include <dlfcn.h>
| ^~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/ea33c8c6aa5091983837609eec5d129902183ef1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit a5d2c379eb (package/openjdk: add ARC HS3x/4x support via "Zero
Assembly Project") forgot to limit the scope of the ARC support.
As of now for ARC we only have fully-interpreted mode AKA "Project Zero"
and so all the JIT'ed modes must be explicitly disabled for ARC.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
- Drop patch (already in version) and so autoreconf
- Update hash of vasprintf.c (changes not related to license:
808166515843f7989076)
https://github.com/file/file/blob/FILE5_41/ChangeLog
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Disable csharp to avoid the following build failure with python since
bump to version 1.12.12 in commit
4e814227ca and
3fd839c76a:
/bin/sh: 1: mcs: not found
Fixes:
- http://autobuild.buildroot.org/results/5f384dbed8e5241f91072bfffa54ba6b9c509751
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Acked-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following build failure raised since bump to version 3.10.1 in
commit 25b1fc2898:
/home/buildroot/autobuild/instance-3/output-1/build/python3-3.10.1/Modules/_hashopenssl.c:244:22: error: implicit declaration of function 'EVP_blake2s256'; did you mean 'LN_blake2s256'? [-Werror=implicit-function-declaration]
244 | digest = EVP_blake2s256();
| ^~~~~~~~~~~~~~
| LN_blake2s256
Fixes:
- http://autobuild.buildroot.org/results/9112571b75aebb0ba5032ef1b16226d9848f5184
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
License hash changed due to full text removal:
6a1c7f0efe
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
License hash change due to full text removal:
307fd35a84
Fixes(python 3.10 compatibility):
File "/usr/lib/python3.10/site-packages/aiohttp_sse/__init__.py", line 107, in wait
File "/usr/lib/python3.10/site-packages/aiohttp_sse/__init__.py", line 144, in _ping
TypeError: sleep() got an unexpected keyword argument 'loop'
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fixes:
File "/usr/lib/python3.10/site-packages/aiohttp/__init__.py", line 6, in <module>
File "/usr/lib/python3.10/site-packages/aiohttp/client.py", line 88, in <module>
File "/usr/lib/python3.10/site-packages/aiohttp/tracing.py", line 5, in <module>
ModuleNotFoundError: No module named 'aiosignal'
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Change the url to the github ofalk repository (SF's repo is MIA; now
everyone and their distros switched over to the Github-hosted fork).
Depend on python3 and host-python3-cython for python bindings.
Remove upstream patches; rework python-makefile.patch to adhere to
git formatting and refresh for 1.14.
Update License hash due to year changes.
Signed-off-by: Adam Duskett <aduskett@gmail.com>
[yann.morin.1998@free.fr: rework commit log, explain switch to Github]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
All patches are upstream. Tested with qemu-system-arm/qemu-system-sparc.
LEGAL license hash changed:
- drop aclocal.m4, no longer provided
- add MIT-covered works
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[yann.morin.1998@free.fr: update license hash]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The previous version bump [1] added the hash of LICENSE.txt but
forgot to update FLARE_GAME_LICENSE_FILES.
[1] 4d09d1b476
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Flare games use OGG audio file format througt SDL2-mixer.
Without OGG support, flare-engine trigger a lot of errors in its
log and fail to start the game.
ERROR: SoundManager: ItemManager: Loading sound /usr/share/flare/mods/fantasycore/soundfx/inventory/inventory_gem.ogg (soundfx/inventory/inventory_gem.ogg) failed: Unrecognized audio format
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
License hash change due to removal of license full text:
aca2c99f82
Drop upstream patch.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As part of commit
4d2ca2be49 ("package/python-setuptools:
bump to version 59.8.0 and split python2 version"), the
HOST_PYTHON_SETUPTOOLS_NEEDS_HOST_PYTHON was moved next to the other
HOST_* variables, but it was also re-added at the original location
during an (incorrect) review process. Fix that up by dropping the
duplicate definition.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- Remove 0013-Add-an-option-to-disable-installation-of-test-module.patch as
it is now upstreamed.
- Refactor and rename all other patches as necessary.
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Python setuptools 44.0 is not compatible with python 3.10. Unfortunately,
python-setuptools 59.8.0 is not compatible with python2. As Buildroot is not
ready to end python2 support, the python-setuptools package must accommodate
both the old version for python2 and the new version for python3.10.
Changes include:
- Add two new directories: package/python-setuptools/44.0.0 and
package/python-setuptools/59.8.0
- Add the appropriate patch and hash files to each directory.
- Modify python-setuptools.mk to support both setuptools 44.0 and 59.8.0
(setuptools 59.8.0 does not have a .zip on pypi anymore, only a tar.gz)
- Point the symlinks in package/python3-setuptools to the files in
package/python-setuptools/59.8.0/
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The current printvars output suffers from a serious design flaw:
variables are not delimited, which makes it impossible to reliably
retrieve the value of variables; only variables that are known to
not contain a \n can be relatively safely extracted.
However, in some cases, it is important to be able to retrieve the
multi-line value of a variable, notably the CMDS or the hooks. One
such use-case (to follow in an unscheduled future) would be to hash
the variables that make up a package "configuration", and cache or
extract the files for that package to speed up the build.
Modeled after printvars and show-info, we introduce show-vars (what a
lack of imagination here) that outputs a json dictionary which keys are
the variable names, and for each variable, provides the raw and expanded
values.
Unlike printvars, we do not provide a way to get either the raw or
expanded value; both are systematically printed; a user will get just
the one is needs. Additionally, strings in JSON are quoted, so there is
no need to provide a way to quote variables; that would not make sense.
Note: for printvars, we require that the user provides an explicit
pattern to filter variables on. This is historical (see fd5bd12379,
Makefile: printvars: don't print anything when VARS is not set). The
underlying reasoning was that printvars is too "raw", and variables are
not well delimited, so printvars was mostly used to extract a few values
here and there, from scripts, or to quickly inspect a specific package's
variables during debugging.
But show-vars, although technically plain-text, being JSON, is not very
human-readable, and is mostly aimed at tools that will parse it with a
real JSON parser, and which will want to have a complete view of a lot
of variables at once. As such, and contrary to printvars, it makes sense
to report on all variables by default, unless the user explicitly
requested a subset.
As a final note: a lot of our variables only make sense in the context
of an actual make target. For example, a variable of package foo, that
contains $(@D)/bar, would expand to .../build/FOO-VERSION/bar. This is
because our CMDS and hooks are expanded as the recipe of a stamp file
that lies in the package build directory.
But for show-info, this falls flat on its face: it is not the stamp file
of a package, so there is no package directory, and show-info itself has
not directory part, so $(@D) expands to '.' (dot).
Additionally, some variables may contain calls to $(shell) (e.g. to call
pkg-config), and this also does not work with show-info.
These two issues make it impossible to emit the correct expanded value
of variables. To be noted: printvars has the exact same limitations for
the exact same reasons.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
External tools may need to peek into the source tree (to check what the
list of patches that were applied), or in the stamp directory (to check
and report on the progress of a build)
Currently, both locations are identical, but semantically different
and an internal implementation detail. Exposing both separately will
allow us to change either without breaking users' scripts. Hopefully.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, our clean-json macro does two things:
- remove excessive commas before a closing list or dictionary;
- escape the backslash.
We are going to need the comma-drop feature of clean-json, but on a
JSON blurb where all the characters, backslash included, are already
all properly escaped, so that we do not need further escape.
So, we drop the backslash escaping from clean-json, and use the newly
introduced mk-json-str helper in every locations where we turn a
Makefile variable into a JSON string.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In quite a few places, we need to generate string that are proper JSON
values or keys.
However, JSON is very strict on what constitute a string, and most JSON
parsers (like jq or python3's json module) are very picky when parsing a
string; any deviation from the spec is immediately sanctioned by a hard
error (jq aborts, python3's json module raise an exception).
Introduce a macro that properly prepares a Makefile value into a valid
JSON string:
- backslash '\' must be escaped;
- double-quotes need to be escaped of course, as they are the string
delimiter in JSON;
- anything in the range [0x00..0x1F] must be escaped; in practice, we
only ever need to escape \n, \t, and ESC (we could add more in the
future if need be);
- finally, we also escape the space, \x20, so that we can call
$(strip) on a JSON blurb (like we do for example do build a
comma-separated list, or when we sanitise the JSON) without losing
multiple spaces where they make sense.
It would have been nice if we had been able to split the macro on
multiple lines, but spaces creep in from everywhere in that case, and
getting rid of them is getting quite nasty... We could introduce
intermediate macros, but meh...
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, we have two functions that build a comma-separated list
of items; one is double-quoting the items, while the other is
single-quoting them. Their naming is not very consistent.
Besides, in a followup change, we will need to build a comma-separated
list of items that are already double-quoted.
Introduce a macro that does just build a comma-separated list, and
use that in the two other macros; rename the existing macro so the
naming is consistent.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Similarly to what we just did for conditionally-set-empty variables,
unconditionally setting empty variables serves no purpose in Makefiles,
as unset variables are just expanded as empty...
Even though we have numerous python packages, the speed gain was not
measurable, with delta much less than the noise.
Still, for consistency, we just do not set those variables.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Setting an unset variable to an empty value is useless in make; an unset
variable just expands to an empty string anyway. So what we do currently
has no side effect:
variable set and not empty -> variable not modified
variable set and empty -> variable not modified
variable unset -> set to an empty string
However, additional variables do have an impact on the parsing time of
the Makefiles, and the more variables, the more collisions in the hash
table used internally by make, which slows down the parsing.
By dropping those conditionally-set-empty variables, we gain about 3%:
Run Before After
1 5.572 5.325
2 5.434 5.354
3 5.490 5.320
4 5.525 5.330
5 5.476 5.330
6 5.511 5.434
7 5.498 5.388
8 5.524 5.371
9 5.479 5.346
10 5.637 5.324
Mean: 5.515 5.352
Yeah, 0.163s does not look like much, and this does not make
autocompletion any more usable. Still, that 3% gain is not to be
ashamed of either.
Note that there are 3 others case where we do set empty variables, but
those are unconditional and serve other purposes:
- pkg-virtual: this is done on purpose to avoid a bug when the
environment may have TOOLCHAIN_VERSION or _SOURCE set, and we really
want those to be empty, so the assignment is not conditional;
- pkg-python: the reason for setting those to empty is dubious at
best; it's been there since the inception of the python infra, back
in 2013; still, the case is different than this patch addresses;
- pkg-toolchain-external: this is the case for a toolchain already
installed, so indeed we want to set _SOURCE and _VERSION to empty.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This package build failure has been fixed by using -mcmodel=large that is
now available in external toolchains as well as buildroot toolchains. So
we can drop its dependency on binutils 21464.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fix the following build failure raised since bump to version 0.18 in
commit 81d14a8625:
aclocal: error: couldn't open directory 'm4': No such file or directory
Fixes:
- http://autobuild.buildroot.org/results/f8e26416e38c83e27e7945343f497a6c9310bfcf
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This allows building and running a full-scale JVM in purely
interpretive mode on ARCv2 processors.
Once JIT'ed version is available for ARC we'll obviously switch to it
to gain a faster execution.
This is only supported for OpenJDK17, so we make OpenJDK11 unavailable
on ARC. However, there was a dependency difference between OpenJDK17
and OpenJDK11 (on host gcc >= 4.9). To avoid any potential
complexities if a package ever needs to "select BR2_PACKAGE_OPENJDK",
this commit moves this host gcc >= 4.9 dependency to
BR2_PACKAGE_OPENJDK itself.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Following the releases of 2021.11 Bootlin toolchains, this commit
represents the result of re-running the gen-bootlin-toolchains script.
The only part that isn't auto-generated are the contents of
Config.in.legacy, which account for the replacement of the RISC-V LP64
toolchain by RISC-V LP64D toolchains.
The complete set of runtime test cases was verified on Gitlab CI:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/437767674
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
toolchains.bootlin.com no longer provides a LP64 RISC-V 64-bit
toolchain, but a more useful LP64D RISC-V 64-bit toolchain. Of course,
the old tarballs remain available, but no new versions of the LP64
toolchain will be produced.
This commit reflects this change in the gen-bootlin-toolchains script.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
