On Thu, 17 Jun 2010, Matthew Seaman wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 17/06/2010 16:04:20, Warren Block wrote:
This is not generally true for shlibs installed from ports, mostly due
to the prevalence of linuxisms like ABI version numbers that aren't
simple integers. Even so, applying a little intelligent scrutiny to the
list of results will help you sort out any spurious linkage.
Could you expand on this part?
find reports 83 links in /usr/local/lib. But only the fake libintl.so.8
is linked to a port-created library but not recorded as part of the
gettext package.
Right. In /usr/local/lib on one machine I happen to have the following:
% find /usr/local/lib -name '*.so.*' -type l -ls | cut -c 89-
/usr/local/lib/libicuio.so.38 -> libicuio.so.38.1
/usr/local/lib/libutempter.so.0 -> libutempter.so.1.1.5
/usr/local/lib/libicuuc.so.38 -> libicuuc.so.38.1
/usr/local/lib/libicule.so.38 -> libicule.so.38.1
/usr/local/lib/libXaw.so.7 -> libXaw7.so.7
/usr/local/lib/libdb-4.8.so.0 -> db48/libdb-4.8.so.0
/usr/local/lib/libdb_cxx-4.8.so.0 -> db48/libdb_cxx-4.8.so.0
/usr/local/lib/libgs.so.8 -> libgs.so.8.71
/usr/local/lib/libXau.so.0 -> /usr/local/lib/libXau.so.6
/usr/local/lib/libicutu.so.38 -> libicutu.so.38.1
/usr/local/lib/libXaw.so.6 -> libXaw6.so.6
/usr/local/lib/libiculx.so.38 -> libiculx.so.38.1
/usr/local/lib/libicui18n.so.38 -> libicui18n.so.38.1
/usr/local/lib/liblua-5.1.so.1 -> lua51/liblua-5.1.so.1
/usr/local/lib/libicudata.so.38 -> libicudata.so.38.1
You can see several different patterns here.
Primus: like libdb-4.8.so.0 or liblua-5.1.so.1 --- the shlib is
installed into a sub-dir of /usr/local/lib and linked back into the main
directory. This is generally used when there are several different
versions of the particular library available in ports.
Secondus: like libXaw.so.6, libXaw.so.7 -- for some reason, the file is
installed with the ABI version as part of the basename of the file and
the link just provides the expected name.
Tertius: like libicuio.so.38 and pretty much all the rest. *BSD uses
.38 as the ABI version number, whereas linux seems to prefer .38.1 --
occasionally this sort of thing is the result of developers being
unclear on the concept of an ABI version number, and just using their
main code version number.
These are all perfectly normal and as installed from ports -- a little
work with 'pkg_which' and 'pkg_info -g' will demonstrate that.
That is essentially what the original Ruby script did, slowly, but
quicker than doing it by hand.
On the other hand, if I'd seen:
/usr/local/lib/libintl.so.8 -> libintl.so.9
where there is a shlib with the standard ABI version pattern as expected
under *BSD, but it's a link to another shlib with a *different* major
version number, then it's pretty clear someone has been bodging things.
Clear enough?
For an interactive method, yes. I'm trying to find something for the
people who thought it was a link-and-forget solution instead of a
temporary workaround.
I just took the approach that a port library with a link that isn't
part of the port is suspicious.
A much faster yet questionable Ruby version is here:
http://www.wonkity.com/~wblock/fakelib/fastfakelib
-Warren Block * Rapid City, South Dakota USA
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[email protected]"
