* 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
