tcf-agent calls RANLIB ( if defined ) after calling AR to
create the archive [1], when RANLIB is set to gcc-ranlib this goes
unnoticed, since calling gcc-ranlib without any arguments silenlty
does nothing and exits with return code 0, however, calling binutils
ranlib or llvm-ranlib does demand library name as commandline option
and since it is not there it exits with code 1
aarch64-poky-linux-musl-llvm-ranlib
OVERVIEW: LLVM ranlib
Generate an index for archives
USAGE: aarch64-poky-linux-musl-llvm-ranlib archive...
OPTIONS:
-h --help - Display available options
-V --version - Display the version of this program
-D - Use zero for timestamps and uids/gids (default)
-U - Use actual timestamps and uids/gids
-X{32|64|32_64|any} - Specify which archive symbol tables should be
generated if they do not already exist (AIX OS only)
aarch64-poky-linux-musl-llvm-ranlib: error: an archive name must be
specified
make: *** [Makefile:53: obj/GNU/Linux/a64/Debug/libtcf.a] Error 1
When we add $@, to RANLIB then it becomes the make variable,
$@ - An automatic Makefile variable that expands to the target name (the
file being built)
so the makefile target now rightly adds the .a filename to RANLIB call.
Sent a patch upstream to add RANLIB for linux [2]
[1] https://gitlab.eclipse.org/eclipse/tcf/tcf.agent/-/blob/master/agent/Makefile?ref_type=heads#L53
[2] https://gitlab.eclipse.org/eclipse/tcf/tcf.agent/-/merge_requests/7
(From OE-Core rev: ee2df4554804cc08906cf7b5c734b234c7913c5f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some of them were introduced by mass-removal of S = WORKDIR/git assignments;
rather than try to fix up (or redo) just these, I've run this sed command over
the whole tree:
sed -i -z -E 's/([ \t\f\v\r]*\n){3,}/\n\n/g' `find . -name *.bb -o -name *.inc`
The rationale is that more than one empty line is wasting vertical screen space, and
does nothing for readability.
(From OE-Core rev: cedc4ff7c9bcfb22a20e43e47f9759f4007a4f1a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removing all the S = ${WORKDIR}/git assignments works because BB_GIT_DEFAULT_DESTSUFFIX
is set to match S from bitbake.conf (which itself is set to match typical tarball
releases).
A few recipes are setting S to a sub-directory of the git tree and need
to be adjusted accordingly.
bzip2 recipe is fetching a tarball and separately cloning tests;
adjust the recipe to put the latter into 'bzip2-tests', instead of 'git'.
devupstream.bbclass no longer needs to rewrite S, and is adjusted accordingly.
Adjust scripts/lib/recipetool/append.py to not hardcode 'git' as unpack
destination.
Adjust kernel-yocto.bbclass to use the git unpack variable instead
of hardcoding 'git' (there's also removal of repetition of
string constants and a correction of workdir/unpackdir mismatch in
one of the if-else branches).
Ensure build-appliance-image recipe does not use 'git' as checkout directory for
poky repo, but rather explicitly name it 'poky'.
Ensure reproducible.py code that looks for git repositories does not
hardcode 'git' but uses the destination set by BB_GIT_DEFAULT_DESTSUFFIX.
Ensure recipetool does not write out unneeded S settings into newly
created recipes that fetch from git.
Adjust selftest to not hardcode 'git' as unpack directory.
(From OE-Core rev: f80c07019ddadaf9c5fb890faabfda7920ecd15e)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A recipe that fetches from git but is otherwise a released version
should not be using _git.bb recipe names.
Put the version in the filename and drop the explicit PV.
(From OE-Core rev: b9eada4db556f06c5a76991db2220272cef66fa3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
