On Wed, 2016-03-23 at 16:23 +0000, Burton, Ross wrote:
On 23 March 2016 at 15:54, Bill Randle
<[email protected]<mailto:[email protected]>> 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
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
