TipsAndTricks/PackagingNonversionedLibrary - Revision history

Henry Bruce: Replaced content with "See TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries"

2017-01-07T00:33:22Z

Replaced content with "See TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries"

← Older revision		Revision as of 00:33, 7 January 2017
Line 1:		Line 1:
	~~= Packaging Unversioned Libraries or Modules =~~		See [[TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries]]

	Libraries in Linux systems are generally versioned so that it is possible to have multiple versions of the same library installed, which eases upgrades and support for older software. For example, suppose that in a versioned library an actual library is called "libfoo.so.1.2", a symbolic link named "libfoo.so.1" points to "libfoo.so.1.2", and a symbolic link named "libfoo.so" points to "libfoo.so.1.2". Given these conditions, when you link a binary against a library, you typically provide the unversioned file name (i.e. -lfoo to the linker). However, the linker follows the symbolic link and actually links against the versioned filename. The unversioned symbolic link is only used at development time. Consequently, the library is packaged along with the headers in the development package ${PN}-dev along with the actual library and versioned symbolic links in ${PN}. Because versioned libraries are far more common than unversioned libraries, the default packaging rules assume versioned libraries.

	It follows that packaging an unversioned library requires a bit of work in the recipe. By default, "libfoo.so" gets packaged into ${PN}-dev, which triggers a QA warning that a non-symlink library is in a -dev package, and binaries in the same recipe link to the library in ${PN}-dev, which triggers more QA warnings. To solve this problem, you need to package the unversioned library into ${PN} where it belongs. Following are the abridged default FILES variables in bitbake.conf:

	~~SOLIBS = ".so.*"~~
	~~SOLIBSDEV = ".so"~~
	~~FILES_${PN} = "... ${libdir}~~/~~lib*${SOLIBS} ..."~~
	~~FILES_SOLIBSDEV ?= "... ${libdir}/lib*${SOLIBSDEV} ..."~~
	~~FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."~~

	SOLIBS defines a pattern that matches real shared object libraries. SOLIBSDEV matches the development form (unversioned symlink). These two variables are then used in FILES_${PN} and FILES_${PN}-dev, which puts the real libraries into ${PN} and the unversioned symbolic link into PN-dev. To package unversioned libraries, you need to modify the variables in the recipe as follows:

	~~SOLIBS = ".so"~~
	~~FILES_SOLIBSDEV = ""~~

	The modifications cause .so to be the real library and unsets FILES_SOLIBSDEV so that no libraries get packaged into PN-dev. The changes are required because unless PACKAGES is changed, PN-dev collects files before PN. PN-dev must not collect any of the files you want in PN.

	Finally, loadable modules (i.e. essentially unversioned libraries that are linked at runtime using dlopen() instead of at build time) should generally be installed in a private directory. However, if they are installed in ${libdir}, then the modules can be treated as unversioned libraries.

	~~== Packaging Pre~~-~~built Libraries ==~~

	~~(insane skip etc)~~

	~~== Manually Installing Libraries ==~~

	~~(oe_libinstall)~~

RossBurton: /* How to Package an Unversioned Library */

2016-08-18T19:38:52Z

How to Package an Unversioned Library

← Older revision		Revision as of 19:38, 18 August 2016
Line 1:		Line 1:
	= ~~How to Package an~~ Unversioned ~~Library~~ =		= Packaging Unversioned Libraries or Modules =

	Libraries in Linux systems are generally versioned so that it is possible to have multiple versions of the same library installed, which eases upgrades and support for older software. For example, suppose that in a versioned library an actual library is called "libfoo.so.1.2", a symbolic link named "libfoo.so.1" points to "libfoo.so.1.2", and a symbolic link named "libfoo.so" points to "libfoo.so.1.2". Given these conditions, when you link a binary against a library, you typically provide the unversioned file name (i.e. -lfoo to the linker). However, the linker follows the symbolic link and actually links against the versioned filename. The unversioned symbolic link is only used at development time. Consequently, the library is packaged along with the headers in the development package ${PN}-dev along with the actual library and versioned symbolic links in ${PN}. Because versioned libraries are far more common than unversioned libraries, the default packaging rules assume versioned libraries.		Libraries in Linux systems are generally versioned so that it is possible to have multiple versions of the same library installed, which eases upgrades and support for older software. For example, suppose that in a versioned library an actual library is called "libfoo.so.1.2", a symbolic link named "libfoo.so.1" points to "libfoo.so.1.2", and a symbolic link named "libfoo.so" points to "libfoo.so.1.2". Given these conditions, when you link a binary against a library, you typically provide the unversioned file name (i.e. -lfoo to the linker). However, the linker follows the symbolic link and actually links against the versioned filename. The unversioned symbolic link is only used at development time. Consequently, the library is packaged along with the headers in the development package ${PN}-dev along with the actual library and versioned symbolic links in ${PN}. Because versioned libraries are far more common than unversioned libraries, the default packaging rules assume versioned libraries.

RossBurton: /* How to Package an Unversioned Library */

2016-08-18T19:38:29Z

How to Package an Unversioned Library

← Older revision		Revision as of 19:38, 18 August 2016
Line 19:		Line 19:

	Finally, loadable modules (i.e. essentially unversioned libraries that are linked at runtime using dlopen() instead of at build time) should generally be installed in a private directory. However, if they are installed in ${libdir}, then the modules can be treated as unversioned libraries.		Finally, loadable modules (i.e. essentially unversioned libraries that are linked at runtime using dlopen() instead of at build time) should generally be installed in a private directory. However, if they are installed in ${libdir}, then the modules can be treated as unversioned libraries.

			== Packaging Pre-built Libraries ==

			(insane skip etc)

			== Manually Installing Libraries ==

			(oe_libinstall)

RossBurton at 19:37, 18 August 2016

2016-08-18T19:37:26Z

← Older revision		Revision as of 19:37, 18 August 2016
Line 1:		Line 1:
	= How to Package an Unversioned Library =		= How to Package an Unversioned Library =

	~~First some background: libraries~~ in Linux systems are generally versioned so that it is possible to have multiple versions of the same library installed, ~~to ease~~ upgrades or support older software. For example in versioned ~~libraries the~~ actual library is called ~~<tt>~~libfoo.so.1.2~~</tt>~~, ~~and then there will be~~ a ~~<tt>~~libfoo.so.1~~</tt> symbolic link~~ to ~~<tt>~~libfoo.so.1.2~~</tt>~~, and ~~finally~~ a ~~<tt>~~libfoo.so~~</tt> symbolic link~~ to ~~<tt>~~libfoo.so.1.2~~</tt>~~. ~~When linking~~ a binary against a library you typically ~~tell it~~ the unversioned file name (~~<tt>~~-lfoo~~</tt>~~ to the linker) ~~but~~ the linker ~~will follow~~ the symbolic link and actually ~~link~~ against the versioned filename. The unversioned symbolic link is only used at development time, so is packaged along with the headers in the development package ~~<tt>~~${PN}-dev~~</tt>,~~ with the actual library and versioned symbolic links in ~~<tt>~~${PN}~~</tt>~~. As versioned libraries are far more common than unversioned libraries, the default packaging rules assume versioned libraries.		Libraries in Linux systems are generally versioned so that it is possible to have multiple versions of the same library installed, which eases upgrades and support for older software. For example, suppose that in a versioned library an actual library is called "libfoo.so.1.2", a symbolic link named "libfoo.so.1" points to "libfoo.so.1.2", and a symbolic link named "libfoo.so" points to "libfoo.so.1.2". Given these conditions, when you link a binary against a library, you typically provide the unversioned file name (i.e. -lfoo to the linker). However, the linker follows the symbolic link and actually links against the versioned filename. The unversioned symbolic link is only used at development time. Consequently, the library is packaged along with the headers in the development package ${PN}-dev along with the actual library and versioned symbolic links in ${PN}. Because versioned libraries are far more common than unversioned libraries, the default packaging rules assume versioned libraries.

	~~However this means~~ that packaging an unversioned library ~~means~~ a bit of work in the recipe, ~~as by default~~ libfoo.so ~~will get~~ packaged into ~~<tt>~~${PN}-dev~~</tt> (triggerring~~ a QA warning that a non-symlink library is in a ~~<tt>~~-dev~~</tt>~~ package), and binaries in the same recipe ~~will~~ link to the library in ~~<tt>~~${PN}-dev~~</tt> (triggering~~ more QA warnings). To solve this the unversioned library ~~needs to be packaged~~ into ~~<tt>~~${PN}~~</tt>~~ where it belongs. ~~These~~ are the (abridged) default ~~<tt>~~FILES~~</tt>~~ variables in ~~<tt>~~bitbake.conf~~</tt>~~:		It follows that packaging an unversioned library requires a bit of work in the recipe. By default, "libfoo.so" gets packaged into ${PN}-dev, which triggers a QA warning that a non-symlink library is in a -dev package, and binaries in the same recipe link to the library in ${PN}-dev, which triggers more QA warnings. To solve this problem, you need to package the unversioned library into ${PN} where it belongs. Following are the abridged default FILES variables in bitbake.conf:

	SOLIBS = ".so.*"		SOLIBS = ".so.*"
	SOLIBSDEV = ".so"		SOLIBSDEV = ".so"
	FILES_${PN} = "... ${libdir}/lib*${SOLIBS} ..."		FILES_${PN} = "... ${libdir}/lib*${SOLIBS} ..."
	FILES_SOLIBSDEV ?= "... ${libdir}/lib*${SOLIBSDEV} ..."		FILES_SOLIBSDEV ?= "... ${libdir}/lib*${SOLIBSDEV} ..."
	FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."		FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."

	~~<tt>~~SOLIBS~~</tt>~~ defines a pattern that matches real shared object libraries~~, and <tt>~~SOLIBSDEV~~</tt>~~ matches the development form (unversioned symlink). These are then used in ~~<tt>~~FILES_${PN}~~</tt>~~ and ~~<tt>~~FILES_${PN}-dev~~</tt>~~ which puts the real libraries into ~~<tt>~~${PN}~~</tt>~~ and the unversioned symbolic link into ~~<tt>~~PN-dev~~</tt>~~. To package unversioned libraries, ~~this needs~~ to ~~be modified as follows~~ in the recipe:		SOLIBS defines a pattern that matches real shared object libraries. SOLIBSDEV matches the development form (unversioned symlink). These two variables are then used in FILES_${PN} and FILES_${PN}-dev, which puts the real libraries into ${PN} and the unversioned symbolic link into PN-dev. To package unversioned libraries, you need to modify the variables in the recipe as follows:

	SOLIBS = ".so"		SOLIBS = ".so"
	FILES_SOLIBSDEV = ""		FILES_SOLIBSDEV = ""

	~~This says that <tt>~~.so~~</tt> is~~ the real library, and unsets ~~<tt>~~FILES_SOLIBSDEV~~</tt>~~ so that no libraries get packaged into ~~<tt>~~PN-dev~~</tt>~~. ~~This is~~ required because unless ~~<tt>~~PACKAGES~~</tt>~~ is changed ~~<tt>~~PN-dev~~</tt>~~ collects files before ~~<tt>~~PN~~</tt>, so <tt>~~PN-dev~~</tt>~~ must not collect any of the files we want in ~~<tt>~~PN~~</tt>~~.		The modifications cause .so to be the real library and unsets FILES_SOLIBSDEV so that no libraries get packaged into PN-dev. The changes are required because unless PACKAGES is changed, PN-dev collects files before PN. PN-dev must not collect any of the files you want in PN.

	~~When installing the library~~, ~~use the <tt>install</tt> command rather than the <tt>oe_soinstall</tt> helper function. <tt>oe_soinstall</tt> will cause an error due to recursive symbolic linking~~ (~~see its implementation in <tt>utils~~.~~bbclass</tt> for more details)~~.		Finally, loadable modules (i.e. essentially unversioned libraries that are linked at runtime using dlopen() instead of at build time) should generally be installed in a private directory. However, if they are installed in ${libdir}, then the modules can be treated as unversioned libraries.

	~~Finally loadable modules,~~ essentially unversioned libraries that are linked at runtime using ~~<tt>~~dlopen()~~</tt>~~ instead of at build time, should generally be installed in a private directory. However if they are installed in ~~<tt>~~${libdir}~~</tt>~~ then ~~they~~ can be treated as unversioned libraries.

Henry Bruce: /* How to Package an Unversioned Library */

2016-08-16T00:18:52Z

How to Package an Unversioned Library

← Older revision		Revision as of 00:18, 16 August 2016
Line 17:		Line 17:

	This says that <tt>.so</tt> is the real library, and unsets <tt>FILES_SOLIBSDEV</tt> so that no libraries get packaged into <tt>PN-dev</tt>. This is required because unless <tt>PACKAGES</tt> is changed <tt>PN-dev</tt> collects files before <tt>PN</tt>, so <tt>PN-dev</tt> must not collect any of the files we want in <tt>PN</tt>.		This says that <tt>.so</tt> is the real library, and unsets <tt>FILES_SOLIBSDEV</tt> so that no libraries get packaged into <tt>PN-dev</tt>. This is required because unless <tt>PACKAGES</tt> is changed <tt>PN-dev</tt> collects files before <tt>PN</tt>, so <tt>PN-dev</tt> must not collect any of the files we want in <tt>PN</tt>.

			When installing the library, use the <tt>install</tt> command rather than the <tt>oe_soinstall</tt> helper function. <tt>oe_soinstall</tt> will cause an error due to recursive symbolic linking (see its implementation in <tt>utils.bbclass</tt> for more details).

	Finally loadable modules, essentially unversioned libraries that are linked at runtime using <tt>dlopen()</tt> instead of at build time, should generally be installed in a private directory. However if they are installed in <tt>${libdir}</tt> then they can be treated as unversioned libraries.		Finally loadable modules, essentially unversioned libraries that are linked at runtime using <tt>dlopen()</tt> instead of at build time, should generally be installed in a private directory. However if they are installed in <tt>${libdir}</tt> then they can be treated as unversioned libraries.

RossBurton: /* How to Package an Unversioned Library */

2016-08-01T19:20:15Z

How to Package an Unversioned Library

← Older revision		Revision as of 19:20, 1 August 2016
Line 1:		Line 1:
	= How to Package an Unversioned Library =		= How to Package an Unversioned Library =

	First some background: libraries in Linux systems are generally versioned so that it is possible to have multiple versions of the same library installed, to ease upgrades or support older software. For example in versioned libraries the actual library is called <tt>libfoo.so.1.2</tt>, and then there will be a <tt>libfoo.so.1</tt> symbolic link to <tt>libfoo.so.1.2</tt>, and finally a <tt>libfoo.so</tt> symbolic link to <tt>libfoo.so.1.2</tt>. When linking a binary against a library you typically tell it the unversioned file name (<tt>-lfoo</tt> to the linker) but the linker will follow the symbolic link and actually link against the versioned filename. The unversioned symbolic link is only used at development time, so is packaged along with the headers in the development package <tt>${PN}-dev</tt>, with the actual library and versioned symbolic links in ${PN}. As versioned libraries are far more common than unversioned libraries, the default packaging rules assume versioned libraries.		First some background: libraries in Linux systems are generally versioned so that it is possible to have multiple versions of the same library installed, to ease upgrades or support older software. For example in versioned libraries the actual library is called <tt>libfoo.so.1.2</tt>, and then there will be a <tt>libfoo.so.1</tt> symbolic link to <tt>libfoo.so.1.2</tt>, and finally a <tt>libfoo.so</tt> symbolic link to <tt>libfoo.so.1.2</tt>. When linking a binary against a library you typically tell it the unversioned file name (<tt>-lfoo</tt> to the linker) but the linker will follow the symbolic link and actually link against the versioned filename. The unversioned symbolic link is only used at development time, so is packaged along with the headers in the development package <tt>${PN}-dev</tt>, with the actual library and versioned symbolic links in <tt>${PN}</tt>. As versioned libraries are far more common than unversioned libraries, the default packaging rules assume versioned libraries.

	However this means that packaging an unversioned library means a bit of work in the recipe, as by default libfoo.so will get packaged into PN-dev (triggerring a QA warning that a non-symlink library is in PN-dev), and binaries in the same recipe will link to the library in PN-dev (triggering more QA warnings). To solve this the unversioned library needs to be packaged into ${PN} where it belongs. These are the (abridged) default FILES variables in bitbake.conf:		However this means that packaging an unversioned library means a bit of work in the recipe, as by default libfoo.so will get packaged into <tt>${PN}-dev</tt> (triggerring a QA warning that a non-symlink library is in a <tt>-dev</tt> package), and binaries in the same recipe will link to the library in <tt>${PN}-dev</tt> (triggering more QA warnings). To solve this the unversioned library needs to be packaged into <tt>${PN}</tt> where it belongs. These are the (abridged) default <tt>FILES</tt> variables in <tt>bitbake.conf</tt>:

	SOLIBS = ".so.*"		SOLIBS = ".so.*"
Line 11:		Line 11:
	FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."		FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."

	SOLIBS defines a pattern that matches real shared object libraries, and SOLIBSDEV matches the development form (unversioned symlink). These are then used in FILES_${PN} and FILES_${PN}-dev which puts the real libraries into PN and the unversioned symbolic link into PN-dev. To package unversioned libraries, this needs to be modified as follows in the recipe:		<tt>SOLIBS</tt> defines a pattern that matches real shared object libraries, and <tt>SOLIBSDEV</tt> matches the development form (unversioned symlink). These are then used in <tt>FILES_${PN}</tt> and <tt>FILES_${PN}-dev</tt> which puts the real libraries into <tt>${PN}</tt> and the unversioned symbolic link into <tt>PN-dev</tt>. To package unversioned libraries, this needs to be modified as follows in the recipe:

	SOLIBS = ".so"		SOLIBS = ".so"
	FILES_SOLIBSDEV = ""		FILES_SOLIBSDEV = ""

	This says that <tt>.so</tt> is the real library, and unsets FILES_SOLIBSDEV so that no libraries get packaged into PN-dev. This is required because unless PACKAGES is changed PN-dev collects files before PN, so PN-dev must not collect any of the files we want in PN.		This says that <tt>.so</tt> is the real library, and unsets <tt>FILES_SOLIBSDEV</tt> so that no libraries get packaged into <tt>PN-dev</tt>. This is required because unless <tt>PACKAGES</tt> is changed <tt>PN-dev</tt> collects files before <tt>PN</tt>, so <tt>PN-dev</tt> must not collect any of the files we want in <tt>PN</tt>.

	Finally loadable modules, essentially unversioned libraries that are linked at runtime using <tt>dlopen()</tt> instead of at build time, should generally be installed in a private directory. However if they are installed in ${libdir} then they can be treated as unversioned libraries.		Finally loadable modules, essentially unversioned libraries that are linked at runtime using <tt>dlopen()</tt> instead of at build time, should generally be installed in a private directory. However if they are installed in <tt>${libdir}</tt> then they can be treated as unversioned libraries.

RossBurton: /* How to Package an Unversioned Library */

2016-08-01T19:17:21Z

How to Package an Unversioned Library

← Older revision		Revision as of 19:17, 1 August 2016
Line 1:		Line 1:
	= How to Package an Unversioned Library =		= How to Package an Unversioned Library =

	First some background: ~~in general~~ libraries in Linux systems are versioned so that it's possible to have multiple versions of the same library installed, to ease upgrades or support older software. In versioned libraries the actual library ~~binary~~ is ~~for example~~ called <tt>libfoo.so.1.2</tt>, and then there will be a <tt>libfoo.so.1</tt> symbolic link to <tt>libfoo.so.1.2</tt>, and finally a <tt>libfoo.so</tt> symbolic link to <tt>libfoo.so.1.2</tt>. When linking a binary against a library ~~then~~ you typically ~~just~~ tell it the unversioned file name (~~for example,~~ <tt>-lfoo</tt> to the linker) but the linker will follow the symbolic ~~links~~ and actually link against the ~~fully-~~versioned filename. The unversioned symbolic link is only used at development time, so ~~in OpenEmbedded (as with all other Linux distros) gets~~ packaged along with the headers in development package <tt>${PN}-dev</tt>. As versioned libraries are far more common than unversioned libraries, the default packaging rules assume versioned libraries.		First some background: libraries in Linux systems are generally versioned so that it is possible to have multiple versions of the same library installed, to ease upgrades or support older software. For example in versioned libraries the actual library is called <tt>libfoo.so.1.2</tt>, and then there will be a <tt>libfoo.so.1</tt> symbolic link to <tt>libfoo.so.1.2</tt>, and finally a <tt>libfoo.so</tt> symbolic link to <tt>libfoo.so.1.2</tt>. When linking a binary against a library you typically tell it the unversioned file name (<tt>-lfoo</tt> to the linker) but the linker will follow the symbolic link and actually link against the versioned filename. The unversioned symbolic link is only used at development time, so is packaged along with the headers in the development package <tt>${PN}-dev</tt>, with the actual library and versioned symbolic links in ${PN}. As versioned libraries are far more common than unversioned libraries, the default packaging rules assume versioned libraries.

	However this means that packaging an unversioned library ~~isn't trivial~~, as by default libfoo.so will get packaged into PN-dev (triggerring a QA warning that a non-symlink library is in PN-dev), and binaries in the same recipe will link to the library in PN-dev (~~and trigger~~ more QA warnings). To solve this the unversioned library needs to be packaged into ${PN} where it belongs~~, so lets have an~~ abridged ~~look at the~~ default FILES variables in bitbake.conf:		However this means that packaging an unversioned library means a bit of work in the recipe, as by default libfoo.so will get packaged into PN-dev (triggerring a QA warning that a non-symlink library is in PN-dev), and binaries in the same recipe will link to the library in PN-dev (triggering more QA warnings). To solve this the unversioned library needs to be packaged into ${PN} where it belongs. These are the (abridged) default FILES variables in bitbake.conf:

	SOLIBS = ".so.*"		SOLIBS = ".so.*"
Line 11:		Line 11:
	FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."		FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."

	SOLIBS defines a pattern that matches real shared object libraries, and SOLIBSDEV matches the development form (unversioned ~~symlinks, typically~~). These are then used in FILES_${PN} and FILES_${PN}-dev which puts the real libraries into PN and the unversioned symbolic link into PN-dev. To package unversioned libraries, this needs to be modified as follows in the recipe:		SOLIBS defines a pattern that matches real shared object libraries, and SOLIBSDEV matches the development form (unversioned symlink). These are then used in FILES_${PN} and FILES_${PN}-dev which puts the real libraries into PN and the unversioned symbolic link into PN-dev. To package unversioned libraries, this needs to be modified as follows in the recipe:

	SOLIBS = ".so"		SOLIBS = ".so"
	FILES_SOLIBSDEV = ""		FILES_SOLIBSDEV = ""

	This says that <tt>.so</tt> is the real library, and unsets FILES_SOLIBSDEV so that no libraries get packaged into PN-dev. This is required because PN-dev collects files before PN, so ~~FILES_PN~~-dev must not collect any of the files.		This says that <tt>.so</tt> is the real library, and unsets FILES_SOLIBSDEV so that no libraries get packaged into PN-dev. This is required because unless PACKAGES is changed PN-dev collects files before PN, so PN-dev must not collect any of the files we want in PN.

			Finally loadable modules, essentially unversioned libraries that are linked at runtime using <tt>dlopen()</tt> instead of at build time, should generally be installed in a private directory. However if they are installed in ${libdir} then they can be treated as unversioned libraries.

RossBurton: RossBurton moved page TipsAndTrick/PackagingNonversionedLibrary to TipsAndTricks/PackagingNonversionedLibrary

2016-07-28T16:36:22Z

RossBurton moved page TipsAndTrick/PackagingNonversionedLibrary to TipsAndTricks/PackagingNonversionedLibrary

← Older revision	Revision as of 16:36, 28 July 2016
(No difference)

RossBurton: /* How to Package an Unversioned Library */

2016-07-28T14:15:04Z

How to Package an Unversioned Library

← Older revision		Revision as of 14:15, 28 July 2016
Line 11:		Line 11:
	FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."		FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."

	SOLIBS defines a pattern that matches real shared object libraries, and SOLIBSDEV matches the development form (unversioned symlinks, typically). These are then used in FILES_${PN} and FILES_${PN}-dev which puts the real libraries into PN and the unversioned symbolic link into PN-dev. To package unversioned libraries, this needs to be ~~subverted~~ as follows in the recipe:		SOLIBS defines a pattern that matches real shared object libraries, and SOLIBSDEV matches the development form (unversioned symlinks, typically). These are then used in FILES_${PN} and FILES_${PN}-dev which puts the real libraries into PN and the unversioned symbolic link into PN-dev. To package unversioned libraries, this needs to be modified as follows in the recipe:

	SOLIBS = ".so"		SOLIBS = ".so"

RossBurton: /* How to Package an Unversioned Library */

2016-07-28T14:14:52Z

How to Package an Unversioned Library

← Older revision		Revision as of 14:14, 28 July 2016
Line 1:		Line 1:
	= How to Package an Unversioned Library =		= How to Package an Unversioned Library =

	First some background: in general libraries in Linux systems are versioned so that it's possible to have multiple versions of the same library installed, to ease upgrades or support older software. In versioned libraries the actual library binary is for example called <tt>libfoo.so.1.2</tt>, and then there will be a <tt>libfoo.so.1</tt> symbolic link to <tt>libfoo.so.1.2</tt>, and finally a <tt>libfoo.so</tt> symbolic link to <tt>libfoo.so.1.2</tt>. When linking a binary against a library then you typically just tell it the unversioned file name (for example, <tt>-lfoo</tt> to the linker) but the linker will follow the symbolic links and actually link against the fully-versioned filename. The unversioned symbolic link is only used at development time, so in OpenEmbedded (as with all other Linux distros) gets packaged along with the headers in development package <tt>${PN}-dev</tt>.		First some background: in general libraries in Linux systems are versioned so that it's possible to have multiple versions of the same library installed, to ease upgrades or support older software. In versioned libraries the actual library binary is for example called <tt>libfoo.so.1.2</tt>, and then there will be a <tt>libfoo.so.1</tt> symbolic link to <tt>libfoo.so.1.2</tt>, and finally a <tt>libfoo.so</tt> symbolic link to <tt>libfoo.so.1.2</tt>. When linking a binary against a library then you typically just tell it the unversioned file name (for example, <tt>-lfoo</tt> to the linker) but the linker will follow the symbolic links and actually link against the fully-versioned filename. The unversioned symbolic link is only used at development time, so in OpenEmbedded (as with all other Linux distros) gets packaged along with the headers in development package <tt>${PN}-dev</tt>. As versioned libraries are far more common than unversioned libraries, the default packaging rules assume versioned libraries.

			However this means that packaging an unversioned library isn't trivial, as by default libfoo.so will get packaged into PN-dev (triggerring a QA warning that a non-symlink library is in PN-dev), and binaries in the same recipe will link to the library in PN-dev (and trigger more QA warnings). To solve this the unversioned library needs to be packaged into ${PN} where it belongs, so lets have an abridged look at the default FILES variables in bitbake.conf:

			SOLIBS = ".so.*"
			SOLIBSDEV = ".so"
			FILES_${PN} = "... ${libdir}/lib*${SOLIBS} ..."
			FILES_SOLIBSDEV ?= "... ${libdir}/lib*${SOLIBSDEV} ..."
			FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."

	~~tl;dr~~:		SOLIBS defines a pattern that matches real shared object libraries, and SOLIBSDEV matches the development form (unversioned symlinks, typically). These are then used in FILES_${PN} and FILES_${PN}-dev which puts the real libraries into PN and the unversioned symbolic link into PN-dev. To package unversioned libraries, this needs to be subverted as follows in the recipe:

	SOLIBS = ".so"		SOLIBS = ".so"
	FILES_SOLIBSDEV = ""		FILES_SOLIBSDEV = ""

	~~(TODO: write more)~~		This says that <tt>.so</tt> is the real library, and unsets FILES_SOLIBSDEV so that no libraries get packaged into PN-dev. This is required because PN-dev collects files before PN, so FILES_PN-dev must not collect any of the files.