conf/distro/include: Add no-static-libs.inc
PATCH 1/1 conf/distro/include: Add no-static-libs.inc
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.
meta/conf/distro/include/no-static-libs.inc new file +19 -0
@@ -0,0 +1,19 @@ +DISABLE_STATIC = " --disable-static" +DISABLE_STATIC_pn-qemu = "" +DISABLE_STATIC_pn-qemu-native = "" +DISABLE_STATIC_pn-qemu-nativesdk = "" +DISABLE_STATIC_pn-pciutils = "" +DISABLE_STATIC_pn-libcap = "" +DISABLE_STATIC_pn-libpcap = "" +# needed by gdb +DISABLE_STATIC_pn-readline = "" +# needed by pseudo +DISABLE_STATIC_pn-sqlite3 = "" +DISABLE_STATIC_pn-sqlite3-native = "" +#EXTRA_OECONF += "${DISABLE_STATIC}" +DISABLE_STATIC_pn-sgml-common-native = "" +DISABLE_STATIC_pn-openjade-native = "" +DISABLE_STATIC_pn-openssl = "" +DISABLE_STATIC_pn-openssl-native = "" +DISABLE_STATIC_pn-nativesdk-openssl = "" +EXTRA_OECONF_append = "${DISABLE_STATIC}"
Quoted 18 lines · Richard 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.
Quoted 3 lines
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.
IMO this is a good change and should become default. It also helps a bit with the questions about static linking vs dynamic linking from legal perspective.
Quoted 35 lines
Signed-off-by Richard Purdie <[email protected]>meta/conf/distro/include/no-static-libs.inc new file +19
-1@@ -0,0 +1,19 @@ +DISABLE_STATIC = " --disable-static" +DISABLE_STATIC_pn-qemu = "" +DISABLE_STATIC_pn-qemu-native = "" +DISABLE_STATIC_pn-qemu-nativesdk = "" +DISABLE_STATIC_pn-pciutils = "" +DISABLE_STATIC_pn-libcap = "" +DISABLE_STATIC_pn-libpcap = "" +# needed by gdb +DISABLE_STATIC_pn-readline = "" +# needed by pseudo +DISABLE_STATIC_pn-sqlite3 = "" +DISABLE_STATIC_pn-sqlite3-native = "" +#EXTRA_OECONF += "${DISABLE_STATIC}" +DISABLE_STATIC_pn-sgml-common-native = "" +DISABLE_STATIC_pn-openjade-native = "" +DISABLE_STATIC_pn-openssl = "" +DISABLE_STATIC_pn-openssl-native = "" +DISABLE_STATIC_pn-nativesdk-openssl = "" +EXTRA_OECONF_append = "${DISABLE_STATIC}" --_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 3 lines · Richard Purdie
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.
I support this being enabled by default on OE-Core as well.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Quoted 8 lines · Otavio Salvador
Quoted 3 lines · Richard Purdie
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.
I support this being enabled by default on OE-Core as well.
Does 'support' mean you are taking care for recipes this is will break throughout our layers?
Andreas
Quoted 4 lines · Andreas Müller
Quoted 2 lines · Otavio Salvador
On Sun, Feb 14, 2016 at 12:28 PM, Richard Purdie
<[email protected]> wrote:
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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.
I support this being enabled by default on OE-Core as well.
Does 'support' mean you are taking care for recipes this is will break throughout our layers?
Poky being the most commonly used one will cause us the same harm; so I see no difference here.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Quoted 4 lines · Andreas Müller
Quoted 2 lines · Otavio Salvador
On Sun, Feb 14, 2016 at 12:28 PM, Richard Purdie
<[email protected]> wrote:
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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.
I support this being enabled by default on OE-Core as well.
Does 'support' mean you are taking care for recipes this is will break throughout our layers?
The ones that fall into distros I care, I will help, however such changes require many hands.
meta-oe is still broken a lot from recent changes in QA checks, EXTRA_OEMAKE, FILES_*.
Including that .inc is easy enough for distros which care (and can fix issues caused by it in recipes they use)
I would prefer to make it default later (like in next release) - even when I would very much like to shorten the build time and sstate sizes of bitbake world on jenkins.
Regards,
Quoted 23 lines · Khem Raj
Quoted 4 lines · Andreas Müller
Quoted 2 lines · Otavio Salvador
On Sun, Feb 14, 2016 at 12:28 PM, Richard Purdie
<[email protected]> wrote:Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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.
I support this being enabled by default on OE-Core as well.
Does 'support' mean you are taking care for recipes this is will break throughout our layers?
The ones that fall into distros I care, I will help, however such changes require many hands.
--
_______________________________________________
Openembedded-core mailing list [email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core