summaryrefslogtreecommitdiffstats
path: root/meta/conf/distro/include/no-static-libs.inc
AgeCommit message (Collapse)Author
2024-01-21shadow: replace static linking with dynamic libraries in a custom location ↵Alexander Kanavin
and bundled with shadow Despite our efforts to make static linking work, there have been new reports of bizarre build failures: https://lists.openembedded.org/g/openembedded-core/message/194006 https://lists.openembedded.org/g/openembedded-core/message/193907 This commit changes back to dynamic linking, but places the libraries in a custom location, per RP's suggestion. (From OE-Core rev: b93562937737e97dbc8cb7c874e9913f6a285a34) 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>
2024-01-12shadow: link executables statically for -native variantAlexander Kanavin
shadow 4.14.x adds a number of libraries it dynamically links with (md, bsd, attr). This causes troubles in setscene tasks where shadow executables are used (such as useradd), as pulling in the needed dynamic libraries needs unpleasant special-casing. (From OE-Core rev: 495ff95eae14a91c94187f78a0b30c7957c9b168) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-08-08conf/distro/no-static-libs: Allow static musl for rustRichard Purdie
When building rust for musl targets we need the static library from musl, so enable it. (From OE-Core rev: 8d0251ec18ec8d7d66a61cca8adcba5ba246cd92) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-01-05no-static-libs.inc: FixesJacob Kroon
* pciutils/libcap/libpcap all seem to build fine even with the flag set * Disable static libraries in libjpeg-turbo-native (From OE-Core rev: 0f018da9416648ea50cbccc3d4424f0b8a9352b6) Signed-off-by: Jacob Kroon <jacob.kroon@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>
2019-11-10pseudo: Drop static linking to sqlite3Richard Purdie
Back in 2010[1] we made pseudo statically link against sqlite3. Since then the world has changed, pseudo now has separate processes for the database in the server and the client and they have separate linking commands. Also, whilst there were concerns about needing specific versions of sqlite3, in the OE environment, this is always the case. [1] http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ad0ac0ecd38fc77daf42485489fccc10a5e1e3e7 The static sqlite3-native is causing us problems, in particular: tmp/work/x86_64-linux/pseudo-native/1.9.0+gitAUTOINC+060058bb29-r0/recipe-sysroot-native/usr/lib/libsqlite3.a(sqlite3.o):(.data.rel+0xb0): undefined reference to `fcntl64' which occurs if sqlite3-native was built on a machine with glibc 2.28 or later and pseudo-native is being built on glibc before that. With dyanmical linking, libc is backwards compatible and works but with static linking it does not. There appears to be no easy way to avoid this other than adding a copy of sqlite3 into the pseudo recipe. Given the static linking doesn't seem to be required any longer due to the separate processes, drop that to fix those issues. (From OE-Core rev: a0c238d40a9cc1f87da0607fddaaef0c31d93720) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-05-15openssl: Remove openssl10Adrian Bunk
OpenSSL 1.0 has been replaced by 1.1, and it would be harder to security-support after the upstream EOL at the end of 2019. (From OE-Core rev: 0f7ffcaa18db7bc27f30c994aafbb9f4f8b2ae7e) Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-02-28qemu: split the native version into usermode and system partsAlexander Kanavin
The rationale is to streamline the overall build. The system parts are only needed to run target images, and so can be built towards the end of the build process. At the same time, the system parts may need gtk+-native and mesa-native which add significantly to the build time. On the other hand, the usermode parts have almost no dependencies and can be built quickly. They are needed at recipes build time to run target binaries, and so are required quite early in the typical build process. (From OE-Core rev: 4a558a5f2db68538e0edad798ddf48eb9510a7d6) Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-09-05no-static-libs: disable static libraries in libjpeg-turboRoss Burton
Previously this was done with the generic autotools support, but CMake doesn't have a standard option so set it explicitly. (From OE-Core rev: 47bd456c1be169fc86788edf0173847b9b0d255b) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-07-26no-static-libs.inc: use `?=' to set a default DISABLE_STATICHongxu Jia
It could be overrided by basic variable setting `='. (From OE-Core rev: fc47018b02a9b96e88735e1b8a0536f9fb268c62) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> 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>
2017-08-13openssl: add a 1.1 versionAlexander Kanavin
Existing openssl 1.0 recipe is renamed to openssl10; it will continue to be provided for as long as upstream supports it (and there are still several recipes which do not work with openssl 1.1 due to API differences). A few files (such as openssl binary) are no longer installed by openssl 1.0, because they clash with openssl 1.1. (From OE-Core rev: da1183f9fa5e06fbe66b5b31eb3313d5d35d11e3) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-10no-static-libs: Add entry for ncursesRichard Purdie
Yes, the option to disable static libraries in boost really is "--without-normal". Add this for ncurses and its variants. (From OE-Core rev: 6b386e444e494b852b59a9f9e80426d564382139) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-04no-static-libs: add missing leading space when using "_append"Robert P. J. Day
The assigned value clearly needs a leading space to be consistent with standard "_append" usage. (From OE-Core rev: f031aa735dbf5e566130e39498033b140bf2b7ba) Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-29no-static-libs.inc: build static libusb1-nativeMartin Jansa
(From OE-Core rev: c8256a88b366fdc9605e31765b4398f99520f483) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-25no-static-libs: just like target and native, nativesk-libcap doesn't like ↵Ross Burton
unrecognised options (From OE-Core rev: 79ec2ec397a35d6405f9c2b3c67e8b9981fbe7be) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-21no-static-libs: remove eglinfoRoss Burton
waf.bbclass disables no-static-libs for all waf recipes, so we don't need to have it explicitly disabled here now. (From OE-Core rev: 6eb64cdd5296c42a46f3485bca403814eec55b2c) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-18no-static-libs.inc: Add libcap-nativeRichard Purdie
We need to disable static flags for libcap-native as well. (From OE-Core rev: b1fa25a238d118f433759102b13896094394ceeb) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-16conf/no-static-libs: add explicit rule for libicalRoss Burton
cmake doesn't have a standard for disabling static libraries so libical needs an explicit statement. (From OE-Core rev: 1a14bc0cc7f1a56833cca7baf12ed5a979854a7b) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-15conf/distro/include: Add no-static-libs.incRichard Purdie
Static libraries are old technology. We've left them around since in previous tests, they only added around 5% to the overall build time. With new and interesting uses of OE, they're becoming more problematic. For example, sstate becomes much larger with static libs enabled which increases the size of eSDK and increases the time taken for sstate operations. Since the static libs contain all the debugging symbols, they're also pretty huge. This patch adds a common include file which allows the user or distro to disable the static libraries in the majority of cases. There are some libs where we do need the static lib, a good example being pseudo-native which uses sqlite3-native static libs. These are left enabled by the include file, as are recipes where --disable-static doesn't work, or isn't supported. This list can likely be reduced over time as individual corner cases are addressed. Maintaining this list in a common location is more desireable than everyone doing it themselves. Poky will switch to using this, OE-Core will need to discuss that as its default. (From OE-Core rev: 773c9e18071d71454473dd81aff911104a2e9bc6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>