/usr/local/lib/compat/pkg/ cleanup ?

Maciej Suszko maciej at suszko.eu
Wed Jul 2 19:32:05 UTC 2014


Mike Clarke <jmc-freebsd2 at milibyte.co.uk> wrote:
> On Wednesday 02 July 2014 08:41:25 Maciej Suszko wrote:
> 
> > 1) find /usr/local -type f -print0 | xargs -0 ldd > /tmp/ldds
> > 2 ) search the ldds file for "not found" or "compat"
> > 3) find what packages affected files belongs to
> > 4) recompile affected packages
> 
> Thanks for that very useful tip.
> 
> I've just done those steps and confirmed that it's OK for me to
> remove everything in /usr/local/lib/compat/pkg. Interestingly it also 
> highlighted several hundred instances of "not found". Rebuilding a 
> couple of ports and setting LD_LIBRARY_PATH to  
> /usr/local/openjdk6/jre/lib/amd64:/usr/local/openjdk6/jre/lib/amd64/server:/usr/local/openoffice-4.0.1/openoffice4/program 
> before re-running ldd sorted out most of them but I was still left 
> with 128 "not found" objects all of which were related to items in 
> /usr/local/lib32.

For Open/LibreOffice, OpenJDK I just omit "not found" ldd messages,
because those packages provide libs which are linked against other libs
located outside well known locations (probably specified
via /var/run/ld*.so.conf according to ldconfig(8)):

/usr/local/openjdk7/jre/lib/amd64/libzip.so:
        libz.so.6 => /lib/libz.so.6 (0x801608000)
        libjava.so => /usr/local/openjdk7/jre/lib/amd64/libjava.so
(0x80181e000) libjvm.so => not found (0)
        libc.so.7 => /lib/libc.so.7 (0x80081e000)
        libjvm.so => not found (0)
        libverify.so => /usr/local/openjdk7/jre/lib/amd64/libverify.so
(0x801a46000) libjvm.so => not found (0)

/usr/local/openjdk7/jre/lib/amd64/server/libjvm.so:
        libm.so.5 => /lib/libm.so.5 (0x8020da000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x802300000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8025c0000)
        libthr.so.3 => /lib/libthr.so.3 (0x8027dc000)
        libc.so.7 => /lib/libc.so.7 (0x80081e000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802a01000)

Setting LD_LIBRARY_PATH do the trick, but in my opinion you can ignore
that.

> For example:
> 
> curlew:/tmp% uname -a
> FreeBSD curlew.lan 9.1-RELEASE-p14 FreeBSD 9.1-RELEASE-p14 #0: Tue
> Jun 3 08:56:12 UTC 2014     root at amd64-
> builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> curlew:/tmp% ldd /usr/local/bin32/wmc
> /usr/local/bin32/wmc:
>         libgettextpo.so.5 => /usr/local/lib32/libgettextpo.so.5 
> (0x281ea000)
>         libc.so.7 => /usr/lib32/libc.so.7 (0x2822f000)
>         libintl.so.9 => not found (0)
>         libiconv.so.3 => not found (0)
> 
> But libintl.so.9 and libiconv.so.3 do exist.

Accroding to rtld(1):

(...) On 64-bit architectures, the linker for 32-bit objects recognizes
all the environment variables listed below, but is being prefixed with
LD_32_

It's been quite a long time since I last used i386 binaries (except
those ran via linuxulator), but your /usr/local/bin32/wmc is compiled
against 32-bit libintl.so.9 and libiconv.so.3 (located
in /usr/local/lib32) and ldd probably see some architecture mismatch,
showing "not found (0)". You can always try to use truss(1) and check
what is going on, where all libraries are searched.


Maybe some developer can shed some light on this topic and explain us
how it's all organized :)
-- 
regards, Maciej Suszko.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20140702/623f5d4d/attachment.sig>


More information about the freebsd-questions mailing list