summaryrefslogtreecommitdiffstats
path: root/meta/recipes-core/glibc/glibc-package.inc
AgeCommit message (Collapse)Author
4 daysrecipes: Update WORKDIR references to UNPACKDIRRichard Purdie
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>
2023-11-20glibc: use nonarch libdir for tmpfiles.dStefan Herbrechtsmeier
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>
2023-09-06glibc-package: Fix conflict error when enable multilib.Lei Maohui
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>
2022-07-23glibc: make glibc-dev depend on kernel headersChen Qi
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>
2022-06-28bitbake.conf/recipes: Introduce add DEV_PKG_DEPENDENCY to change ↵Richard Purdie
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>
2022-02-25glibc: fix multilib headers conflict for armYi Zhao
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>
2022-02-10meta: Remove libsegfault and catchsegvKhem Raj
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>
2022-02-10glibc: Upgrade to 2.35Richard Purdie
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>
2021-11-10meta: use ln -rs instead of lnrRoss Burton
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>
2021-10-09glibc: Drop libcidn packageFred Liu
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>
2021-09-07systemd: '${systemd_unitdir}/system' => '${systemd_system_unitdir}'Robert P. J. Day
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>
2021-08-22Fix conflict error when enable multilib.leimaohui
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>
2021-08-18glibc: package the stub .a libaries into glibc-devRoss Burton
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>
2021-08-12glibc: Add missing symlinks for libpthread and librt dev filesKhem Raj
(From OE-Core rev: 3a02079bbc29c64f3807f24f9b69ee02f765bec7) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-08-12glibc: Upgrade to 2.34 releaseKhem Raj
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>
2021-08-02Convert to new override syntaxRichard Purdie
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>
2021-06-21glibc: fix path to place zdump in the tzcode packageTony Battersby
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>
2021-04-18glibc: Rename glibc src packageKhem Raj
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>
2021-02-21glibc-package.inc: Fix arm multlib header issue with struct_stat.hzhengruoqin
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>
2020-10-06glibc: do_stash_locale must not delete files from ${D}Richard Purdie
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>
2020-06-09glibc: move ld.so.conf back to main packageRasmus Villemoes
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>
2020-05-27multilib/recipes: Use new RecipePostKeyExpansion eventRichard Purdie
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>
2020-05-18glibc: Do not synthesize wordsize.h for arm multilibsKhem Raj
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>
2020-02-18glibc-package.inc: fix multilib headers conflictKai Kang
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>
2020-02-02glibc: merge libc-common.bbclass into glibc.bbRoss Burton
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>
2020-02-02glibc-package.inc: Remove warnings about unpacked directoriesRichard Purdie
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>
2019-12-06glibc: fix ldconfig packaging issueMing Liu
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>
2019-11-11glibc: move ldconfig to its own packageAndreas Oberritter
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>
2019-09-19glibc: Make it build without ldconfig in DISTRO_FEATURESPeter Kjellerstedt
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>
2019-09-16glibc: Move DISTRO_FEATURE specific do_install code for target recipe onlyKhem Raj
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>
2019-09-06Clean up remnants of glibc-initialNathan Rossi
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>
2019-08-07glibc-package.inc: Add linux-libc-headers-dev to glibc-devMark Hatle
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>
2019-07-15glibc-package.inc: Do not use bitbake variable syntax for shell variablesPeter Kjellerstedt
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>
2019-07-10glibc / glibc-locale: Fix stash_locale determinism problemsJason Wessel
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>
2019-07-03glibc/glibc-locale: Fix do_stash_locale to work with usrmerge and multilibsJason Wessel
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>
2019-06-30glibc: Fix multilibs + usrmerge buildsJason Wessel
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>
2019-03-18glibc: fix do_populate_sdk fail when multilib usedChangqing Li
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>
2019-02-26glibc: Install AArch64 loader link correctly for usrmerge+multilibMike Crowe
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>
2019-01-31glibc: systemd and sysvinit are not mutually exclusiveJonas Bonn
(From OE-Core rev: 0990d77d99a9ba81e21961f9633df10ccef4b1a4) Signed-off-by: Jonas Bonn <jonas@norrbonn.se> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-09-27glibc-package.inc: correct intention for deleting /usr/lib as neededAwais Belal
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>
2018-08-19glibc: re-package for libnss-dbChen Qi
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>
2018-08-15glibc: Disable crypt support in glibcKhem Raj
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>
2018-08-14glibc: Make bits/wordsize.h multilibbed againDaniel Díaz
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>
2018-07-26glibc: Avoid multilibbing on wordsize.hDaniel Díaz
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>
2018-05-09glibc: Drop obsolete rpc and libnslKhem Raj
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>
2018-05-04glibc: use oe_multilib_header on bits/floatn.hChen Qi
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>
2018-03-30glibc-package: fix locale cleanup logicKoen Kooi
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>
2018-01-30meta: don't use deprecated functions from utils.bbclassRoss Burton
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>
2018-01-29glibc: Adapt do_install_append_aarch64() for usrmergePeter Kjellerstedt
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>
2018-01-13glibc/nscd: do not cache for netgroup by defaultJackie Huang
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>