Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Aug 2013 21:25:17 -0700
From:      Kevin Oberman <rkoberman@gmail.com>
To:        Boris Samorodov <bsam@passap.ru>
Cc:        FreeBSD ports list <freebsd-ports@freebsd.org>
Subject:   Re: How to create lib (and run) dependency list at Makefile
Message-ID:  <CAN6yY1t1Z7pDD0763mpMi%2BhhtDgpoFMDK_sk2_M=uSx%2Bx5hmwg@mail.gmail.com>
In-Reply-To: <52093464.2030601@passap.ru>
References:  <52093464.2030601@passap.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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!
> --
> WBR, Boris Samorodov (bsam)
> FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
>

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).

First, when rolling a port it is impractical to try to track down every
library that a library I need links to. And it is totally unnecessary For
the port and package, as the ports system automagically take care of
including dependencies of dependencies. When running he executable, the
rtld takes care of all of this.

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 why I prefer running pkg_libchk. Then I KNOW what ports
need rebuilding after a library version bump. port(master|upgrade) -r will
also do this correctly, 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).
-- 
R. Kevin Oberman, Network Engineer
E-mail: rkoberman@gmail.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1t1Z7pDD0763mpMi%2BhhtDgpoFMDK_sk2_M=uSx%2Bx5hmwg>