Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Jul 2014 21:31:52 +0200
From:      Maciej Suszko <maciej@suszko.eu>
To:        Mike Clarke <jmc-freebsd2@milibyte.co.uk>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: /usr/local/lib/compat/pkg/ cleanup ?
Message-ID:  <20140702213152.52897e3b@leo.lan>
In-Reply-To: <2862326.RiQ9aP1WQA@curlew.lan>
References:  <20140627161801.GA38362@admin.sibptus.tomsk.ru> <20140628135325.GA55592@admin.sibptus.tomsk.ru> <20140702084125.50882034@helium> <2862326.RiQ9aP1WQA@curlew.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/e8r1RLQ3dE0rbaNuncaDjiz
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Mike Clarke <jmc-freebsd2@milibyte.co.uk> wrote:
> On Wednesday 02 July 2014 08:41:25 Maciej Suszko wrote:
>=20
> > 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
>=20
> Thanks for that very useful tip.
>=20
> 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=20
> highlighted several hundred instances of "not found". Rebuilding a=20
> couple of ports and setting LD_LIBRARY_PATH to =20
> /usr/local/openjdk6/jre/lib/amd64:/usr/local/openjdk6/jre/lib/amd64/serve=
r:/usr/local/openoffice-4.0.1/openoffice4/program=20
> before re-running ldd sorted out most of them but I was still left=20
> with 128 "not found" objects all of which were related to items in=20
> /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 =3D> /lib/libz.so.6 (0x801608000)
        libjava.so =3D> /usr/local/openjdk7/jre/lib/amd64/libjava.so
(0x80181e000) libjvm.so =3D> not found (0)
        libc.so.7 =3D> /lib/libc.so.7 (0x80081e000)
        libjvm.so =3D> not found (0)
        libverify.so =3D> /usr/local/openjdk7/jre/lib/amd64/libverify.so
(0x801a46000) libjvm.so =3D> not found (0)

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

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

> For example:
>=20
> 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@amd64-
> builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
>=20
> curlew:/tmp% ldd /usr/local/bin32/wmc
> /usr/local/bin32/wmc:
>         libgettextpo.so.5 =3D> /usr/local/lib32/libgettextpo.so.5=20
> (0x281ea000)
>         libc.so.7 =3D> /usr/lib32/libc.so.7 (0x2822f000)
>         libintl.so.9 =3D> not found (0)
>         libiconv.so.3 =3D> not found (0)
>=20
> 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 :)
--=20
regards, Maciej Suszko.

--Sig_/e8r1RLQ3dE0rbaNuncaDjiz
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlO0Xi4ACgkQCikUk0l7iGrOfACfYmeF63g2KKEIA/CnDVs4Bb7G
QzsAn16sScSj1mpo1ynffhplwK9NnFPG
=YzhA
-----END PGP SIGNATURE-----

--Sig_/e8r1RLQ3dE0rbaNuncaDjiz--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140702213152.52897e3b>