[OE-core] [PATCH] insane.bbclass: tighten lib_re and exec_re patterns to avoid false positive

Randle, William C william.c.randle at intel.com
Wed Mar 23 16:40:05 UTC 2016


On Wed, 2016-03-23 at 16:23 +0000, Burton, Ross wrote:

On 23 March 2016 at 15:54, Bill Randle <william.c.randle at intel.com<mailto:william.c.randle at intel.com>> wrote:
+    lib_re = re.compile("^/lib.+\.so(\.\d+){0,3}$")
+    exec_re = re.compile("^%s.*/lib.+\.so(\.\d+){0,3}$" % exec_prefix)


I worry that this goes too far in the other way, my Debian host has a library called /usr/lib/libblas.so.3gf.

Maybe we should add a "is this an ELF" test into the libdir check instead?  That might kill performance though, and this is just a sanity check.

Any other thoughts?

Ross

Ok, I found a library on my FC23 system named "libdmraid.so.1.0.0.rc16" in /usr/lib64. The available documentation on sonames I found states:


"Every shared library has a special name called the ``soname''. The soname has the prefix ``lib'', the name of the library, the phrase ``.so'', followed by a period and a version number that is incremented whenever the interface changes (as a special exception, the lowest-level C libraries don't start with ``lib''). A fully-qualified soname includes as a prefix the directory it's in; on a working system a fully-qualified soname is simply a symbolic link to the shared library's ``real name''.


"Every shared library also has a ``real name'', which is the filename containing the actual library code. The real name adds to the soname a period, a minor number, another period, and the release number. The last period and release number are optional. The minor number and release number support configuration control by letting you know exactly what version(s) of the library are installed. Note that these numbers might not be the same as the numbers used to describe the library in documentation, although that does make things easier."


That implies there should only be upto three numbers after the .so, to the ".rc16" on the end violates that rule, and the implication is these should be version *numbers*, not version strings, which would mean your library ending in .3gf violates that rule.


I guess some rules are just meant to be broken. Sigh.


    -Bill



More information about the Openembedded-core mailing list