Date: Wed, 14 Aug 2013 00:26:24 +0400 From: Boris Samorodov <bsam@passap.ru> To: Kevin Oberman <rkoberman@gmail.com> Cc: FreeBSD ports list <freebsd-ports@freebsd.org> Subject: Re: How to create lib (and run) dependency list at Makefile Message-ID: <520A9670.2080401@passap.ru> In-Reply-To: <CAN6yY1t1Z7pDD0763mpMi%2BhhtDgpoFMDK_sk2_M=uSx%2Bx5hmwg@mail.gmail.com> References: <52093464.2030601@passap.ru> <CAN6yY1t1Z7pDD0763mpMi%2BhhtDgpoFMDK_sk2_M=uSx%2Bx5hmwg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
13.08.2013 08:25, Kevin Oberman пишет:
> On Mon, Aug 12, 2013 at 12:15 PM, Boris Samorodov <bsam@passap.ru> wrote:
>
>> Hi All,
>>
>> recently I've upgaded my ports. Then I get:
>> -----
>> % pkg_libchk -a
>> rasqal-0.9.30: /usr/local/bin/roqet misses libcurl.so.6
>> rasqal-0.9.30: /usr/local/lib/librasqal.so.3 misses libcurl.so.6
>> -----
>>
>> So, I assume that textproc/rasqal was not bumped after ftp/curl update.
>> The dependency was not specified. I tested a patch and filed a PR.
>> But while working with port I get strange (at least to me) results.
>>
>> The binary file which is installed by textproc/rasqal is bin/roqet.
>> Let's see which libraries (installed from ports) it uses:
>> -----
>> % ldd -f '%p\n' /usr/local/bin/roqet | grep '/usr/local'
>> /usr/local/lib/librasqal.so.3
>> /usr/local/lib/libraptor2.so.0
>> /usr/local/lib/libicuuc.so.50
>> /usr/local/lib/libxslt.so.2
>> /usr/local/lib/libyajl.so.2
>> /usr/local/lib/libxml2.so.5
>> /usr/local/lib/libiconv.so.3
>> /usr/local/lib/libcurl.so.7
>> /usr/local/lib/libicudata.so.50
>> -----
>>
>> That means this file depends upon (origins):
>> -----
>> converters/libiconv
>> devel/icu
>> devel/yajl
>> ftp/curl
>> textproc/libxml2
>> textproc/libxslt
>> textproc/raptor2
>> -----
>>
>> Am I right that those ports should be specified as LIB (or RUN)
>> dependencies for textproc/rasqal?
>>
>> Here is the current run dependencies (for the whole port, not just
>> one binary file!):
>> -----
>> % make -C /usr/ports/textproc/rasqal run-depends-list
>> /usr/ports/devel/pcre
>> /usr/ports/textproc/raptor2
>> -----
>>
>> Seems that I'm mistaken somewhere, because 6(!) library dependencies
>> are not registered!
>>
>> PS. All those ports shows up as indirect dependencies (checked with
>> 'make all-depends-list'). But imho they should be a _direct_ ones.
>>
>> Am I wrong here? Thanks!
>
> Yes, you are wrong, but it's not obvious.
>
> When a program links to a sharable library, it also links to any library to
> which the sharable links.
> As it turns out, libraptor2.so does, in fact, link to libcurl.so (and a
> bunch of others).
Thanks. I've got some other information (by google) on the matter as
well. The problem appears to be more complex then I guessed. :-(
> First, when rolling a port it is impractical to try to track down every
> library that a library I need links to.
Is it impractical vs a (possible) non working soft?
> And it is totally unnecessary For
> the port and package,
For me it's the only possible solution for now (until libtool is fixed
to register only direct dependencies).
> as the ports system automagically take care of
> including dependencies of dependencies.
Here is an example of this automagic:
-----
% portmaster -a
===>>> Starting check of installed ports for available updates
===>>> All ports are up to date
===>>> Exiting
% ldd /usr/local/bin/roqet| grep curl [*]
libcurl.so.6 => /usr/local/lib/compat/pkg/libcurl.so.6 (0x800cec000)
libcurl.so.7 => /usr/local/lib/libcurl.so.7 (0x802b80000)
-----
> When running he executable, the
> rtld takes care of all of this.
It seems to me that rtld takes care of libraries with different minor
versions, but not major.
(A note: I think about automatic package updates as a goal).
> There are some real complications that pop up now an again. One is figuring
> out which ports need to be re-built. You can't just scan Makefiles for
> LIBDEPENDS.
That's true only because there is no policy to register all
dependencies (written to library or binary).
> That's why I prefer running pkg_libchk. Then I KNOW what ports
> need rebuilding after a library version bump.
Yes, it's good with manual interventing.
> port(master|upgrade) -r will
> also do this correctly,
Well, but it's totally inefficient to run "portmaster -r" on every
major bump for every library at /usr/local.
> but will also cause many ports that DON'T link to
> the sharable that had a version bump. They're safe, but not efficient.
> pkg_libchk is both safe and efficient, but takes a little thought. (The
> magic incantation is:
> pkg_libchk -o | grep BUMPED_LIB | cut -d: -f1 | sort | uniq
> This will provide a list of what needs rebuilding. (Similar commands using
> other tools like awk will also work, of course).
Hm, I tried to figure out what pkg_libchk do. Seems that it just use
readelf.
OK. I used the wrong instrument -- ldd (it shows all recursive
dependencies). Let's try objdump (the result is the same for readelf):
-----
% objdump -x /usr/local/bin/roqet | awk '/NEEDED/ {print $2}'
librasqal.so.3
libraptor2.so.0
libcurl.so.6
libssl.so.7
libcrypto.so.7
libicuuc.so.50
libxslt.so.2
libxml2.so.5
libiconv.so.3
libyajl.so.2
libz.so.6
libm.so.5
libc.so.7
-----
That effectively means that if any of those libraries change major
version the binary (and package!) should be rebuild.
Note: the binary uses libcurl.so.6. Ldd on this file [*] shows that
some library is already rebuild and use libcurl.so.7.
Do you think that rtld may fix this situation? That packages built
against different major library versions may even install?
So (imho): if we want to use packages for autoupgrades (isn't it one of
the main goals of pkgng?) then we _have to_ register all dependencies
written to libraries and binaries. Until libtool is fixed...
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?520A9670.2080401>