Age | Commit message (Collapse) | Author |
|
Since we want to be able to stop unpacking to WORKDIR, correct the WORKDIR
references in recipe do_compile/do_install tasks to use UNPACKDIR in the
appropraite places instead.
(From OE-Core rev: d73595df69667fe9d12ecd407b77a0b8dae2109c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The documentation of systemd states that /etc/tmpfiles.d should be
reserved for the local administrator and packages should put their files
in /usr/lib/tmpfiles.d [1].
[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
(From OE-Core rev: e2bebef14a64c510b8f5b0a21f15347d6919c218)
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Signed-off-by: Lukas Funke <lukas.funke@weidmueller.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
file /usr/include/bits/math-vector.h from install of lib32-libc6-dev-2.38-r0.armv7ahf_neon conflicts with file from package libc6-dev-2.38-r0.aarch64
Reference to the git log of glibc, upstream modified math-vector.h for
aarch64, so this file has many differences from aarch32.
For detailed modifications, please refer to these two commit log of
glibc:
commit 4a9392ffc27ad280f84779eea3ba01f2c134d1d8
commit 78c01a5cbeb6717ffa2d4d66bb90ac5c39bd81a9
(From OE-Core rev: ecfa84f5bb238ef2252d6491a6cde2c5fd202213)
Signed-off-by: Lei Maohui <leimaohui@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The linux kernel headers are necessary for glibc-dev, so
we need to use RDEPENDS instead of DEV_PKG_DEPENDENCY which
specifies RRECOMMENDS.
Currently, in case of NO_RECOMMENDATIONS set to "1", linux
kernel headers are not pulled in by glibc-dev, causing error
like below when compiling.
fatal error: linux/errno.h: No such file or directory
The problem could be reproduced by setting NO_RECOMMENDATIONS
to "1" and then running:
bitbake core-image-minimal -c populate_sdk
bitbake core-image-minimal -c testsdk
(From OE-Core rev: fdb16e1a78c2abcc8ac89678b1b250ca4fa9c0d9)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
RDEPENDS:${PN}-dev
There is a pattern that several recipes need to break the dependency of ${PN}-dev
on ${PN}, most often as ${PN} may be be empty. Add a new variable to parameterise
this and allow it to be changed more easily.
(From OE-Core rev: a5b381c0f45c590a762647a9956a8f41e2e2315e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixes:
Error: Transaction test error:
file /usr/include/bits/dl_find_object.h conflicts between attempted installs of lib32-libc6-dev-2.35-r0.armv7vet2hf_vfp and libc6-dev-2.35-r0.cortexa57
file /usr/include/bits/rseq.h conflicts between attempted installs of lib32-libc6-dev-2.35-r0.armv7vet2hf_vfp and libc6-dev-2.35-r0.cortexa57
file /usr/include/bits/timesize.h conflicts between attempted installs of lib32-libc6-dev-2.35-r0.armv7vet2hf_vfp and libc6-dev-2.35-r0.cortexa57
(From OE-Core rev: 0982c2bc19f4cacd72fd43f93c6a0a4d45a75c6a)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Glibc has dropped them starting with 2.35 see [1]
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=65ccd641bacea33be23d51da737c2de7543d0f5e
(From OE-Core rev: 95c61d834596263ab1dd1fb1f8c8dbcc9104a935)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Package /usr/bin/ld.so in a separate package
ld.so is a new tool which is added as a symlink to original dynamic
linker so make it available with same name across architectures which is
useful to leveral features like --preload, --audit, and --list-diagnostics
more accessible to end users
(From OE-Core rev: 2658dcbcfc3db814af1ee104303effc1b6cfa489)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
lnr is a script in oe-core that creates relative symlinks, with the same
behaviour as `ln --relative --symlink`. It was added back in 2014[1] as
not all of the supported host distributions at the time shipped
coreutils 8.16, the first release with --relative.
However the oldest coreutils release in the supported distributions is
now 8.22 in CentOS 7, so lnr can be deprecated and users switched to ln.
[1] 6ae3b85eaffd1b0b6914422e8de7c1230723157d
(From OE-Core rev: 1ca455a98de4c713f58df0a537d4c982d256cd68)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
libcidn has been dropped since glibc 2.28
(From OE-Core rev: cf83790728ad569af01300f793754c0108c78b4e)
Signed-off-by: Fred Liu <yclw3d2y@live.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Repo-wide replacement to use newer variable to represent systemd
system unitdir directory.
(From OE-Core rev: 5ace3ada5c54500c71becc8e0c6eddeb8bc053e3)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
file /usr/include/bits/pthread_stack_min.h conflicts between attempted installs of libc6-dev-2.34-r0.aarch64 and lib32-libc6-dev-2.34-r0.armv7ahf_neon
(From OE-Core rev: 40d131ff65d36022ca604d1153c5948eb888a2e3)
Signed-off-by: Lei Maohui <leimaohui@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In glibc 2.34, the libraries libpthread, libdl, libutil, libanl have
been integrated into libc. To retain compatibility with old binaries the
shared libaries are still shipped but are empty, and to keep software
building there are empty static libraries.
However, these static libraries get packaged into glibc-staticdev (as
they should be), but by this design they should be in glibc-dev.
https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
(From OE-Core rev: f42658198193dcf88814513e1fa09bf484777079)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 3a02079bbc29c64f3807f24f9b69ee02f765bec7)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
bump localedef to get __attr_access_none and __attr_access definitions
replace /bin/bash instead of @BASH@ in ldd as @BASH@ has been substituted with /bin/bash now
package libc_malloc_debug.so.0
Detailed changelog [1]
[1] https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
(From OE-Core rev: af4e1306a78cf8c508dd911f02c103af81bc1af5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
zdump should be included in the tzcode package but is instead included
in the glibc-utils package due to an incorrect path in the recipe.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14427
(From OE-Core rev: bf3892cef3381f6bd277228cdcc5a00fcfe3f3af)
Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Since glibc uses custom PACKAGES, it misses using ${PN}-src and as a
result it uses libc-src for name which means creating rdep on glibc src
package becomes difficult since bitbake can not resolve rdep = glibc-src
back to glibc recipe and bails out on builds
Missing or unbuildable dependency chain was: ['glibc-src']
ERROR: Required build target 'valgrind' has no buildable providers.
Missing or unbuildable dependency chain was: ['valgrind', 'glibc-src']
(From OE-Core rev: 816c8529f05271aba3d414ab2e68506ac7b6ec69)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fix build error under multilib as following:
"file /usr/include/bits/struct_stat.h conflicts between attempted installs of lib32-libc6-dev-2.33-r0.armv7ahf_neon and libc6-dev-2.33-r0.aarch64"
(From OE-Core rev: 163ec51715e939fe9ff3f87c2af46a77e1a8edea)
Signed-off-by: Zheng Ruoqin <zhengrq.fnst@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
do_stash_locale doesn't run in fakeroot context, do_install does. We therefore
shouldn't delete files that do_install has added or it leaves potentially
problemtic entries in the fakeroot database. Leaving the files around
doesn't change or break anything else.
(From OE-Core rev: f18817f5340d06f7b4bb846a83b48731a1b9c4bc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There are cases where one doesn't want ldconfig on target (e.g. for
read-only root filesystems, it's rather pointless), yet one still
needs ld.so.conf to be present at image build time:
When some recipe installs libraries to a non-standard location, and
dutifully drops in a file in /etc/ld.so.conf.d/foo.conf, we need the
ld.so.conf containing the
include /etc/ld.so.conf.d/*.conf
stanza to get those other locations picked up.
So change the packaging logic so that there's always an ld.so.conf
present when the build-time ldconfig runs.
The ld.so.conf and ld.so.conf.d/*.conf files don't take up much
room (at least not compared to the 700K binary ldconfig), and they
might be needed in case ldconfig is installable, so leave them
alone.
In case of a read-only rootfs, one could add some logic to remove them
if one really wants to shave those few dozens of bytes off.
While here, fix typos in the bb.note (add spaces) so one can just
copy-paste the line from the log-file and redo the command.
(From OE-Core rev: a4cdda012f613d8d80203b9f5fc737d8511d16ce)
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There are issues with multilib due to the ordering of events where some
functions see the remapped multilib dependencies and some do not. A significant
problem is that the multilib class needs to make some changes before key expansion
and some afterwards but by using existing event handlers, some code sees things
in a partially translated state, leading to bugs.
This patch changes things to use a new event handler from bitbake which makes the
ordering of the changes explcit.
The challenge in doing this is that it breaks some existing anonymous python and
dyanmic assignments. In some cases these used to be translated and no longer are,
meaning MLPREFIX has to be added. In some cases these are now translated and the
MLPREFIX can be removed.
This change does now make it very clear when MLPREFIX is required and when it is
not, its just the migration path which is harder. The patch changes the small number
of cases where fixes are needed.
In particular, where a variable like RDEPENDS is conditionally extended (e.g.
with an override), MLPREFIX is now required.
This patch also reverts:
base: Revert 'base.bbclass: considering multilib when setting LICENSE_EXCLUSION'
This reverts 6597130256a1609c3e05ec5891aceaf549c37985 as the changes
to multilib datastore handling mean its no longer necessary.
(From OE-Core rev: b3fda056a674889cd9697e779de023d4f993d3ce)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This has been constant source of trouble, because it is fundamental file
which sets machine word length and everything else builts on top of that
so when it is sythesized like this, where the sythesize template itself
needs wordsize.h to determine machine word length, it creates the
catch-22 problem, which is seen when building things like bpf, or
running clang-tidy etc. where compiler internal defines may not be used
this ends up in all sorts of problems. Now that glibc provides exact
same header for arm and aarch64, its no longer needed to be multilibbed
here
(From OE-Core rev: d223f85f8a18b1343f186122425f18f32706065b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Pass bits/endianness.h and bits/struct_rwlock.h to oe_multilib_header in
glibc-package.inc to fix files conflict:
| Error: Transaction check error:
| file /usr/include/bits/endianness.h conflicts between attempted installs of lib32-libc6-dev-2.31-r0.armv7vet2hf_vfp and libc6-dev-2.31-r0.aarch64
| file /usr/include/bits/struct_rwlock.h conflicts between attempted installs of lib32-libc6-dev-2.31-r0.armv7vet2hf_vfp and libc6-dev-2.31-r0.aarch64
(From OE-Core rev: 0af9ff84348197b8b314f7c0d3757cab629daa94)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There's only one user of libc-common now that we don't ship both glibc and
eglibc, so copy the contents directly into the recipe.
[ YOCTO #12135 ]
(From OE-Core rev: a0bff0db1eeb128776757d5f3d0bc1ebdc135498)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If documemtation generation is disabled, the recipe throws warnings about
unpackaged files. Avoid this.
(From OE-Core rev: 811a5b1b4d4da97caaca2779c8aa5687cbf0c609)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
ldconfig should be prior to glibc-utils in PACKAGES variable, or else
ldconfig binary would not be split to its own package, hence will lead
to runtime issues for the packages that depending on ldconfig, like
systemd.
(From OE-Core rev: 5101aecacfb5a8e48bba74b538742bef9409b999)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Only recommend its installation, if it's enabled in distro features.
(From OE-Core rev: fda7cd9328ba26e0023d7ddfaa23f73b59443a08)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The removal of the supposedly empty /etc when ldconfig is not in
DISTRO_FEATURES seems to be a remnant from a long time ago when nothing
else was installed in /etc. However, that is no longer the case as,
e.g., nscd.conf is always installed to /etc now.
(From OE-Core rev: f66c02130d11154088d86c96fedd88e9d2bca723)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
nativesdk-glibc should be spared of recompile when the distro features
are changed e.g. ldconfig is not in
DISTRO_FEATURES, this happens when sdk with musl and another one with
glibc is built
Fixes
Variable do_install value changed:
...
-DISTRO_FEATURES{ldconfig} = Set
+DISTRO_FEATURES{ldconfig} = Unset
(From OE-Core rev: e7af0204e6051489ef5646fbca2509a42e04bb72)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
s
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Remove remnants of the glibc-initial recipe.
(From OE-Core rev: 332b1e21db3e0cbeeb14f12dd6aeedb89b76d761)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Without linux-libc-headers-dev being added to the libc6-dev as a RDEPENDS,
the system may fail to install the necessary libc headers.
This can happen when NO_RECOMMENDATIONS = "1" is defined.
During the 'testsdk' this results in failures that look like:
fatal error: linux/errno.h: No such file or directory
# include <linux/errno.h>
^~~~~~~~~~~~~~~
This also matches the behavior of musl, which does not suffer from this
problem.
(From OE-Core rev: ad31c908c8267166ce6cce9d5085ef2ac099a6c5)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Using bitbake variable syntax (i.e., ${FOO}) for shell variables is
bad practice. First of all it is confusing, but more importantly it
can lead to weird problems if someone actually defines a bitbake
variable with the same name as the shell variable.
Also correct the indentation in stash_locale_cleanup().
(From OE-Core rev: 4e303063db731feae192314bab2ca16d26192dbb)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When using sstate, or performing an incremental build any change to
the do_stash_locale() will cause a build failure because
do_stash_locale() was destroying the results obtained from the
do_install() with several mv operations. A recent change to
do_stash_locale() for a different problem illustrated a number of
build failures for users in the community.
To fix the problem, do_stash_locale() must use copy operations instead
of the mv operations. Because this is changed to a copy, the sysroot
and package stage need to remove the files that would have been
previously removed. The correct "fixup" code to deal with the removal
already existed in the previous do_poststash_install_cleanup(). All
that needed change was the path to where to remove the files
from the sysroot and package stages.
In order to force a re-compilation of glibc some unused white space
was removed from do_compile() for glibc. I could not find any other
way around this and we don't want to have all the community folks to
have another iteration where they have to remove their tmp directories
or purge some portion of the sstate. It also makes this change
bisectable. If the change to the glibc is not included, it will fail
with the following message:
=====
| DEBUG: Executing shell function do_prep_locale_tree
| tar: i18n: Cannot stat: No such file or directory
| tar: Exiting with failure status due to previous errors
| gzip: /poky/build/tmp/work/core2-64-poky-linux/glibc-locale/2.29-r0/locale-tree//usr/share/i18n/charmaps/*gz.gz: No such file or directory
=====
After this one time change I tested changing only the
do_stash_locale() function and it now works well because it is
deterministically operating off the sstate data or a local build.
(From OE-Core rev: fedc57a41a15bca1d96d14e25e2df0bb1eca904d)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The do_stash_locale was not working consistently across the 4 build
configurations and the multilib, usrmerge configuration would fail
entirely with the obscure message:
| DEBUG: Executing shell function do_prep_locale_tree
| tar: i18n: Cannot stat: No such file or directory
| tar: Exiting with failure status due to previous errors
| gzip: /poky/build/tmp/work/core2-64-poky-linux/glibc-locale/2.29-r0/locale-tree//usr/share/i18n/charmaps/*gz.gz: No such file or directory
| WARNING: /poky/build/tmp/work/core2-64-poky-linux/glibc-locale/2.29-r0/temp/run.do_prep_locale_tree.124690:1 exit 1 from 'gunzip $i'
Here is the 4 build configurations without the patch applied:
A) x86-64 no multilibs, no usrmerge
find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v nscd.service |wc -l
909
B) x86-64 no multilibs, usrmerge
find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v nscd.service |wc -l
909
C) x86-64 multilibs, no usrmerge
find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v nscd.service |wc -l
885
D) x86-64 multilibs, usrmerge
find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v nscd.service |wc -l
864
The issue here is that all the moves should be processed first, then a
copy should be made of the lib directories, but only in the case they
are different when using the usrmerge feature. Even though the build
worked for the multilib configuration without usrmerge, the content
was not the same.
After applying the patch the same number of files are in all the
configurations. The list of files was also diffed, after normalizing
the directory names to ensure all the correct files were copied.
Ultimately there are probably additional files that should be pruned
from what is copied to the stated_locale, but the purpose of this
patch is make it 100% consistent between the build types and fix the
builds.
(From OE-Core rev: 33c2e7b4944af22ca47b53d1f85d03426f169bb7)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The build of glibc fails when you have multilibs enabled + the distro
feature usrmerge. Here is an example configuration:
===
MACHINE = "qemux86-64"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_append = " systemd "
DISTRO_FEATURES_append += " usrmerge"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
===
This will fail with the following error:
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: glibc-2.28-r0 do_poststash_install_cleanup: Function failed: do_poststash_install_cleanup (log file is located at /poky/build/tmp/work/core2-64-poky-linux/glibc/2.28-r0/temp/log.do_poststash_install_cleanup.107893)
ERROR: Logfile of failure stored in: /poky/build/tmp/work/core2-64-poky-linux/glibc/2.28-r0/temp/log.do_poststash_install_cleanup.107893
The fix is to not perform the rmdir check when using the multilib + usr/merge, namely:
if [ "${libdir}" != "${exec_prefix}/lib" ] && [ "${root_prefix}/lib" != "${exec_prefix}/lib" ]; then
This will evaluate as follows (collecting the output from bitbake -e glibc)
* no multilibs no usrmerge
if [ "/usr/lib" != "/usr/lib" ] && [ "/lib" != "/usr/lib" ]; then
* no multilibs yes usrmerge
if [ "/usr/lib" != "/usr/lib" ] && [ "/usr/lib" != "/usr/lib" ]; then
* yes multilibs no usrmerge
if [ "/usr/lib64" != "/usr/lib" ] && [ "/lib" != "/usr/lib" ]; then
* yes multilibs yes user merge
if [ "/usr/lib64" != "/usr/lib" ] && [ "/usr/lib" != "/usr/lib" ]; then
(From OE-Core rev: c5640f8c8663c8f81125bf7c5bc2ef8e9fe55315)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
fix below error:
file /usr/include/bits/procfs-id.h conflicts between attempted installs of lib32-libc6-dev-2.29-r0.armv7vet2hf_vfp and libc6-dev-2.29-r0.aarch64
file /usr/include/bits/procfs.h conflicts between attempted installs of lib32-libc6-dev-2.29-r0.armv7vet2hf_vfp and libc6-dev-2.29-r0.aarch64
file /usr/include/bits/shmlba.h conflicts between attempted installs of lib32-libc6-dev-2.29-r0.armv7vet2hf_vfp and libc6-dev-2.29-r0.aarch64
(From OE-Core rev: 1e9120096da81171e9213b0b78df0aff7002de15)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The AArch64 little-endian ABI requires that the dynamic loader is always
available at /lib/ld-linux-aarch64.so.1. Similarly, the big-endian ABI
requires that the dynamic loader is always available at
/lib/ld-linux-aarch64_be.so.1.
glibc-package.inc contains code that tries to ensure this, but
unfortunately it is defeated by the combination of multilib and usrmerge
because it does not take into account that /lib is the same as /usr/lib
with usrmerge when it adds the loader path to libc_baselibs and when it
attempts to show that /usr/lib is empty in do_poststash_install_cleanup.
This results in the symlink not being included in the package and a build
failure due to rmdir failing.
Richard Purdie also suggested[1] that ${nonarch_base_libdir} should not be
used as a synonym for /lib in this case.
This hopefully-fixed version always sets ARCH_DYNAMIC_LOADER and then uses
${root_prefix}/lib/${ARCH_DYNAMIC_LOADER} to refer to the dynamic loader
which works with both multilib and usrmerge. Since ARCH_DYNAMIC_LOADER is
only non-empty if the symlink is required, the code to create it can move
to do_install_append. Then do_poststash_install_cleanup needs to be taught
that ${exec_prefix}/lib may not be empty if the dynamic loader symlink is
there.
It appears not to be possible to specify the name of the loader via a
variable with an override, since the _aarch64 override is applied even for
_aarch64-be, so I've set the loader name using ${TARGET_ARCH} instead.
Build-tested and inspected core-image-minimal rootfs with:
* AArch64 no multilib (real loader in correct place)
MACHINE = "qemuarm64"
* AArch64 multilib (symlink in correct place)
MACHINE = "qemuarm64"
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
require conf/multilib.conf
* AArch64 usrmerge (real loader in correct place)
DISTRO_FEATURES += "usrmerge"
MACHINE = "qemuarm64"
* AArch64 multilib usrmerge (symlink in correct place)
DISTRO_FEATURES += "usrmerge"
MACHINE = "qemuarm64"
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
require conf/multilib.conf
* big-endian versions of all of the above by also setting
DEFAULTTUNE = "aarch64_be".
(building glibc only.)
* x86_64 (real loader in /lib as before)[2]
MACHINE = "qemux86"
* x86_64 multilib (real loader in /lib64 as before)
MACHINE="qemux86-64"
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
require conf/multilib.conf
I also tested leaving an unwanted file in ${exec_prefix}/lib for
do_poststash_install_cleanup to detect, and I believe the detection always
worked correctly.
[1] http://lists.openembedded.org/pipermail/openembedded-core/2018-November/276120.html
(From OE-Core rev: a705c0782c863ee960d65b5109168a4587a0a7b7)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 0990d77d99a9ba81e21961f9633df10ccef4b1a4)
Signed-off-by: Jonas Bonn <jonas@norrbonn.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In case the baselib is lib64 we would want to delete /usr/lib
after removing the /usr/lib/locale dir and the implementation
wanted to do that earlier as well but the fault was checking
an already removed dir (/usr/lib/locale) before trying to
remove /usr/lib as that check would always fail.
Now we simply try to delete /usr/lib after deleting
/usr/lib/locale to make sure it deletes cleanly and is empty
at the time of deletion.
(From OE-Core rev: 4dad1568f8f84ec9de4bf7235822f77a8ee6a413)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
On other distros like ubuntu/centos, libnss-db usually provides:
- The libraries
- The Makefile to create database
(in /var/db for centos, /var/lib/misc/ for ubuntu)
- The makedb command (it's in glibc-common for centos7)
What we had is:
- The libraries are in glibc-extra-nss
- The Makefile is removed
- The makedb command is in glibc-utils (lack of dependency)
So when glibc-extra-nss is installed but glibc-utils is not,
we see error like:
nscd[165]: 165 checking for monitored file `/var/db/group.db': No such file or directory
nscd[165]: 165 checking for monitored file `/var/db/passwd.db': No such file or directory
And there is not an easy way to create these databases.
To fix the issue:
- Re-package the libraries into libnss-db
- Don't remove the Makefile and add it in libnss-db
- Add RDEPENDS for libnss-db on glibc-utils
- Provide a shell script, makedbs.sh, to generate the db files.
This is to avoid dependency on 'make'.
Notes:
1. For external toolchain, an extra package 'libnss-db' need to be provided
If replacing glibc from core.
2. I've check the git history of nss/db-Makefile, the last two functionality
fix is as below.
- fix non-portable `echo -n` usage -- Date: Thu Aug 6 04:14:20 2015 -0400
- Fix db makefile rule for group.db -- Date: Fri Nov 11 14:43:36 2011 +0100
So I think this file is stable enough. And using makedbs.sh which is crafted according
to that file is not likely to cause maintanence problem.
(From OE-Core rev: 13cf502fce8956f95fdc8ac0c7a37d741223bcc9)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Drop packaging libcrypt from 2.28+ onwards
We have independent crypt implementation coming from libxcrypt
(From OE-Core rev: 6146b8c4216daf56a69f4e3531861302df6a63a2)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As reported by ChenQi, leaving bits/wordsize.h out of being
multilibbed introduced a problem in building the SDK for
arm64:
Error: Transaction check error:
file /usr/include/bits/wordsize.h conflicts between attempted installs of lib32-libc6-dev-2.27-r0.armv7vet2hf_vfp and libc6-dev-2.27-r0.aarch64
This effectively reverts commit a74c77d6.
(From OE-Core rev: 90ad502bf8faa233e25cf297c1eeefcb0367aea3)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Once another header #includes <bits/wordsize.h>, there is a
potential recursion going on because the
multilib_header_wrapper.h #includes <bits/wordsize.h> again!
This should not happen because an __arm__ (32-bits) or an
__aarch64__ (64-bits) environment guarantees that we will
be getting the correct definition, but when building against
a different target (like BPF), recursion is what happens.
This can be seen, for instance, when building eBPF programs
from the kernel with `clang -target bpf', such as the ones
located in linux/tools/testing/selftests/bpf/.
(From OE-Core rev: a74c77d6168101e88c3a3bce7130f4f52cfab95d)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Aníbal Limón <anibal.limon@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
use libnsl2 and rpcsvc-proto packages
(From OE-Core rev: 9dc9983901cec364ea57a72b9da1a0396b60663a)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When building SDK via populate_sdk for qemuarm64 with multilib
enabled, we would have conflict about bits/floatn.h at populate_sdk
time.
file /usr/include/bits/floatn.h conflicts between attempted ins
talls of libc6-dev-2.27-r0.aarch64 and lib32-libc6-dev-2.27-r0.armv7vehf_vfp
Apply oe_multilib_header on this header file to fix the problem.
(From OE-Core rev: 650c59c8b6796cf4797ca1860be85f6ccf50bcd2)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If ${libdir} is a subdirectory of ${prefix}/lib, e.g. /usr/lib/aarch64-linux, the cleanup logic will delete libc.so.
This bit of code was added in 2012 (git show b744f4cc) to remove /usr/lib/locale, this commit makes it remove that directory recursively and afterwards remove /usr/lib, erroring out if it's non-empty.
Tested with a plain (/usr/lib), a 64-bit (/usr/lib64) and a multiarch (/usr/lib/aarch64-linux) build. I strongly suspect this whole bit of cleanup isn't needed anymore, but my testing is too limited to be certain.
(From OE-Core rev: d8f4c7794f15f7071ee8e621d7964cb4b4134630)
Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
These functions were moved to meta/lib/oe in 2010 and the base_* functions in
utils.bbclass were intended to be a short-term compatibility layer. They're
still used in a few places, so update the callers to use the new functions.
(From OE-Core rev: c97acbd034532895ce57c6717ed1b3ccc7900b0d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Change hardcoded /lib to ${nonarch_base_libdir} to correctly adapt the
code in do_install_append_aarch64() for when usrmerge is enabled in
DISTRO_FEATURES.
(From OE-Core rev: ac373c9f760463d989d6a1eb3a14b7c5b255b9d4)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We don't have /etc/netgroup by default, so do not
cache for netgroup by default to avoid:
nscd[529]: 529 disabled inotify-based monitoring for file `/etc/netgroup': No such file or directory
nscd[529]: 529 stat failed for file `/etc/netgroup'; will try again later: No such file or directory
(From OE-Core rev: 10007bcd30a96470059f9d5b19cf698243486f06)
(From OE-Core rev: 0adedfc2bf8981819fbbf8b1884da44c7082d1a6)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|