summaryrefslogtreecommitdiffstats
path: root/meta/recipes-core/meta/uninative-tarball.bb
Commit message (Collapse)AuthorAgeFilesLines
* uninative-tarball: install the full set of gconv modulesAlexander Kanavin2023-07-301-9/+1
| | | | | | | | | | | | | | | | msgfmt from gettext-native 0.22 is using iconv() to convert data to utf-8 from arbitrary source encodings (previous versions of gettext did not do this conversion): https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=5412a4f79929004cb6db15d545e07dc953330e8d As this is happening at build time, and the source encodings are specified by upstream projects in translation files, we need the full set to cover all of them. (From OE-Core rev: 8a23d9f499c7784379822ef69f4812a562a90887) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Add libgccRichard Purdie2023-01-091-0/+1
| | | | | | | | | | | | | | | We ship libpthread with uninative. when uninative is active we're seeing failures like: libgcc_s.so.1 must be installed for pthread_cancel to work Aborted which is since we don't have a libgcc that matches libpthread. Add libgcc to avoid these errors. (From OE-Core rev: a134a7186b2266378bc0b08c134e169a943eedde) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* buildtools-tarball/uninative-tarball/meta-ide-support: Drop useless meta classRichard Purdie2021-09-231-1/+0
| | | | | | | | | | | | The class adds an emtpy PACKAGES setting but most code now uses the nopackages class which is much clearer. It also adds recursive do_build dependencies which don't really serve any useful purpose any more. Simplify the code and drop the class use. (From OE-Core rev: 030d56e2e8ece93472adc51fe467221d846c9ac0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Add a dependency on nativesdk-glibc-dbgPeter Kjellerstedt2021-03-141-0/+1
| | | | | | | | | | | This adds the debug symbols for the binaries included in the uninative tar ball. These are needed if one wants to run valgrind on a native binary when uninative is used. Or get complete backtraces using gdb. (From OE-Core rev: 13775feac21f0df50d4b3db19f6c79f10cf397f5) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* nativesdk-sdk-provides-dummy: Add /bin/shRichard Purdie2020-08-221-0/+1
| | | | | | | | | | | | | | By doing this we can revert b18c32ab6bc9c4f1953e9f79aa39bc92d1c4e30d which was a pretty ugly hack anyway and now means the different providers are all being handled consistently. Anyone with SDK recipes will need to ensure nativesdk-sdk-provides-dummy is included in those builds (or an equivalent). This is a good thing to do anyway. (From OE-Core rev: dd2c603befdd65c92c6196d5b103568249766b3e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Add libxcrypt-compatRichard Purdie2019-06-201-0/+1
| | | | | | | | | | This avoids sstate/uninative relocation issues where a binary was built against a system with libcrypt.so.1 or libcrypt.so.2 and then run on the opposite by ensuring both libraries are in uninative. (From OE-Core rev: 6089bfbc059c8bebb63ae6b0bafe8fe035548ac0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Use xz compression and SDK_ARCHIVE_CMDuninative-2.5Richard Purdie2019-05-291-1/+1
| | | | | | | | | Switch uninative to use xz compression instead of bzip2. We can then directly use the SDK_ARCHIVE_CMD. (From OE-Core rev: c2e30917542297c0dbef2868d4aeebc05b13ef8b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Fix file generation after class changesRichard Purdie2019-05-291-1/+1
| | | | | | | | | | OE-Core rev: 57a33048a89a422cfdc986d3489c67b2d297e1e7 renamed the tar_sdk function but didn't fix this recipe. This leads to broken uninative tarballs as the internal structure isn't correct. Fix this. (From OE-Core rev: 1cfe7cbb20a0eedd46ab6ee57f8d49bc652f818a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Add nativesdk-libnss-nis to resolve glibc symbol issuesRichard Purdie2018-07-241-0/+1
| | | | | | | | | We need this to avoid symbol mismatch issues for binaries that use this on newer systems which then won't run on older ones where it isn't present. (From OE-Core rev: 39c1719a32ed5567e3bf2df5c4f9068d0f5a9400) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Add libjis and euc-jp gconv filesKhem Raj2018-05-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | packages like fontforge-native fail with mysterious errors like | ../../git/inc/gwwiconv.h:44:21: error: conflicting types for ‘gww_iconv_close’ | #define iconv_close gww_iconv_close | ^~~~~~~~~~~~~~~ | ../../git/inc/gwwiconv.h:37:13: note: previous declaration of ‘gww_iconv_close’ was here | extern void gww_iconv_close( gww_iconv_t cd); | ^~~~~~~~~~~~~~~ The reason behind this is that a check for iconv fails during native configure run, the check fails because the autoconf test to check for iconv pokes for these gconv's in test runs before declaring iconv support successful. Therefore when uninative is active the package fails to build but when uninative is inactive all works fine. this patch fixes that (From OE-Core rev: b4f5ed7a8bb2f76ab4a50b3f0073a9d18a51923e) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* nativesdk-glibc: Split glibc and libcrypt to use libxcrypt insteadRichard Purdie2018-04-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fedora28[1] has decided to go ahead and use libxcrypt to replace libcrypt from glibc despite the change not having merged into glibc upstream yet. This breaks the use of uninative in OE on fedora28 since binaries there are now using new symbols only found in libxcrypt. libxcrypt is meant to be backwards compatible with libcrypt but not the reverse. Since this will impact OE in the next release cycle, this changes nativesdk only to use this new model and adds libxcrypt to work in that case. This allows us to build a uninative which is compatible with fedora28 and previous other OSes. In order to work, recipes will now need to depend on virtual/crypt where they use libcrypt since its now a separate library and we can't depend on it from glibc to preseve backwards compatibility since glibc needs to build first. For now, only the problematic nativesdk recipes have been fixed up. For target use, the default provider remains glibc for now. Assuming this change is merged into upstream glibc, we will need to roll this change out for the target but we will do this in the next release cycle when we can better deal with the resulting bugs. [1] https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt Original patch from Charles-Antoine Couret <charles-antoine.couret@essensium.com>, tweaked by RP to add virtual provides, SkipRecipe for libxcrypt and other minor tweaks. (From OE-Core rev: c1573cb7faeb296fe7077a60d02443d5ed5bded0) Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@essensium.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: drop deltask package/packagedataMing Liu2017-07-251-2/+0
| | | | | | | | | | They are redundant since nopackages are being inherited. (From OE-Core rev: 2414e9f286d34af2db5982a988b78362decb7961) Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: glibc-gconv-{utf-16, cp1252} for binutils windresNathan Rossi2017-03-241-0/+3
| | | | | | | | | | | | | | The windres binutils binary which is used for Windows resource files requires utf-16 and cp1252 encoding support in order to correctly generate resource files with strings. As such when using uninative to build mingw resources for a nativesdk target the windres binary is executed on the native host, thus using the uninative libc and gconv modules. (From OE-Core rev: 778fb2342da55e202cfb7af04bbf120c1b68620a) Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Remove LIC_FILES_CHKSUM from recipes without SRC_URIOlaf Mandel2016-10-281-2/+0
| | | | | | | | | | | | | | | | LICENSE and LIC_FILES_CHKSUM apply to the sources specified by SRC_URI, not to the recipe itself. As such a license declaration for a source-less recipe makes little sense. The LICENSE declaration is mandatory, but LIC_FILES_CHKSUM can be removed in such cases. Remove the LIC_FILES_CHKSUM declarations from all recipes that do not need it. CC: Paul Eggleton <paul.eggleton@linux.intel.com> (From OE-Core rev: b18fa5f2f2f46afc6fdc58f4d29679dea9c36c43) Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* buildtools/uninative-tarball: Fix deployment overlap issuesuninative-1.4Richard Purdie2016-09-231-2/+2
| | | | | | | | | | | | | | | | | | We still have problems where deploying SDKMACHINE=i686 can cause removal of SDKMACHINE=x86_64 artefacts. The reason is that x86_64 is a BUILD_ARCH as well as an SDK_ARCH and the manifest namespaces overlap. To fix this, set PACKAGE_ARCH and the stamp-extra-into to include SDK_OS. SDK_OS may not be entirely correct but it is what sstate.bbclass uses for nativesdk and fixing that is a separate issue. This is confirmed to resolve artefact problems on the AB which have been delaying a new uninative release. (From OE-Core rev: 1dbc6ec4ca061570d2482c9abebcf720298db9b7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Make stamp independentRichard Purdie2016-09-221-0/+6
| | | | | | | | | | | | | | | | The uninative tarball only contains nativesdk compoents. It should not get regenerated when MACHINE changes for example. Currently its sstate arch is also incorrect so changing SDKMACHINE results in other variants being removed from the deploy directory. This patch removes the target architecture dependencies so that deploy artefacts can overlap and it doesn't continually rebuild. This also fixes various autobuilder/release artefact issues we're having as a result of these issues. (From OE-Core rev: 6edd0b8dccc6e1e21f2ef87013e2e0a40d19b0d6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: add SDKMACHINE to stamps-extra-infoJoshua Lock2016-09-211-1/+1
| | | | | | | | | | Otherwise the stamps for x86-64 and i686 uninative tarballs match and we can't deploy both to the DEPLOYDIR. (From OE-Core rev: 2a9603759fe87d6326c145f6213ffffeb6afc6ae) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* buildtools-tarball/uninative-tarball: Fix for working with populate_sdk ↵Richard Purdie2016-09-041-2/+6
| | | | | | | | | | | | | | | | under sstate control Firstly, these recipes are not target (MACHINE) specific so they should by SDK_ARCH based, not PACKAGE_ARCH. Also fix use of SDK_DEPLOY -> SDKDEPOLYDIR after other recent changes. Together these fixes avoid various build failures and ensure the tarballs only get built once rather than multiple times. (From OE-Core rev: 894c9b6ded702897ae4084ef75959cdc8cc6f7a3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/lib: Update xrange -> range for python3Richard Purdie2016-06-021-1/+1
| | | | | | | | xrange() no longer exists in python 3, use range() (From OE-Core rev: d022b4335100612d6596cc4c4956cb98ed5873cc) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Add glibc-gconv-iso8859-1 for guileRichard Purdie2016-03-071-0/+3
| | | | | | (From OE-Core rev: a8181c2d3a9e51569d77ab2ad9950b27a1113294) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: respect SDKMACHINE when buildingRoss Burton2016-02-281-4/+6
| | | | | | | | | | | | | So that a single machine can build multiple architectures for the uninative-tarball respect SDK_ARCH instead of BUILD_ARCH. This means a x86-64 host can build a i686 uninative-tarball by setting SDKMACHINE=i686. (From OE-Core rev: 11b0e7e1cb29fd1fbe06bdb5606a55b92ecdcc89) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add 850 codepage to uninative-tarballRandy Witt2015-10-271-0/+1
| | | | | | | (From OE-Core rev: 6211c8060d408134dfa6c00b23b517c439e4c1e7) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: delete the packagedata taskChen Qi2015-04-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This task is meaningless for uninative-tarball as the package task has been deleted. Besides, sometimes it would cause problems. To reproduce, use the following command. bitbake uninative-tarball -c cleansstate && bitbake uninative-tarball && bitbake uninative-tarball -c clean && bitbake uninative-tarball The error is something like below. File: 'sstate.bbclass', lineno: 33, function: sstate_installpkg 0029: bb.build.exec_func(f, d) 0030: 0031: for state in ss['dirs']: 0032: prepdir(state[1]) *** 0033: os.rename(sstateinst + state[0], state[1]) 0034: sstate_install(ss, d) 0035: 0036: for plain in ss['plaindirs']: 0037: workdir = d.getVar('WORKDIR', True) Exception: OSError: [Errno 2] No such file or directory [YOCTO #7597] (From OE-Core rev: 8f905077aaed3dbeeed04787add1cf725fa87bdc) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: fix dependency on patchelfTyler Hall2015-03-251-1/+2
| | | | | | | | | | | | | | | | | DEPENDS doesn't actually add the dependency on patchelf-native to the populate_sdk task. SDK_DEPENDS does this, but move the append to after inheriting the base class so it does not get overwritten. Without this, uninative-tarball fails to build in a clean workspace on a system without patchelf. [YOCTO #7467] (From OE-Core rev: 0631c2b52432ddf86292351d605b65941d2a8be2) Signed-off-by: Tyler Hall <tylerwhall@gmail.com> Acked-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Actually use bzip2 for compression.Randy Witt2015-02-241-1/+1
| | | | | | | | | | uninative.bbclass uses -xjf for decompression so actually run the data through bzip2. (From OE-Core rev: 84665b4e894a949591d812f1cdc1745a376bf95f) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative-tarball: Update eglibc -> glibcRichard Purdie2014-10-021-1/+1
| | | | | | (From OE-Core rev: 2b85b3f33af5157cd4b6f8a6dc737015c85018c3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative: Add uninative - a way of reusing native/cross over multiple distrosRichard Purdie2014-09-231-0/+48
These patches are the start of a new idea, a way of allowing a single set of cross/native sstate to work over mutliple distros, even old ones. The assumption is that our own C library is basically up to date. We build and share a small tarball (~2MB) of a prebuilt copy of this along with a patchelf binary (which sadly is C++ based so libstdc++ is in there). This tarball can be generated from our usual SDK generation process through the supplied recipe, uninative-tarball. At the start of the build, if its not been extracted into the sysroot, this tarball is extracted there and configured for the specified path. When we install binaries from a "uninative" sstate feed, we change the dynamic loader to point at this dynamic loader and C librbary. This works exactly the same way as our relocatable SDK does. The only real difference is a switch to use patchelf, so even if the interpreter section is too small, it can still adjust the binary. Right now this implements a working proof of concept. If you build the tarball and place it at the head of the tree (in COREBASE), you can run a build from sstate and successfully build packages and construct images. There is some improvement needed, its hardcoded for x86_64 right now, its trivial to add 32 bit support too. The tarball isn't fetched right now, there is just a harcoded path assumption and there is no error handling. I haven't figured out the best delivery mechanism for that yet. BuildStarted is probably not the right event to hook on either. I've merged this to illustrate how with a small change, we might make the native/cross sstate much more reusable and hence improve the accessibility of lower overhead builds. With this change, its possible the Yocto Project may be able to support a configured sstate mirror out the box. This also has positive implications for our developer workflow/SDK improvements. (From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-10 21:14:16 +0000