Subject: Re: packages, rpaths, compat, oh my!
To: Richard M Kreuter <kreuter@progn.net>
From: Lubomir Sedlacik <salo@Xtrmntr.org>
List: netbsd-help
Date: 09/19/2004 00:26:31
--sXc4Kmr5FA7axrvy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

hi,

On Sat, Sep 18, 2004 at 06:00:26PM -0400, Richard M Kreuter wrote:
>=20
> I'm running a few NetBSD 1.6 and 2.0 beta hosts, and would like to
> share /usr/pkg and /usr/local across all of them. The 2.0 hosts'
> kernels have COMPAT_16 enabled, and have the compat16 package
> installed, but programs that require library versions from NetBSD 1.6
> don't run without help, because nothing causes those programs to use
> the libraries in /usr/pkg/emul/netbsd16. [1]
>=20
> I'm reluctant to maintain separate sets of binaries for the two
> versions, and I'll probably have to keep the 1.6 hosts around for a
> bit, so I tried to solve the problem by using rpaths. By inspection,
> adding the relevant lib directories under emul/netbsd16 to the rpath
> in CFLAGS/LDFLAGS at compile time can produce executables that will
> work as desired on both the 1.6 and 2.0 hosts. This works for several
> programs I build manually (without pkgsrc), but somehow executables
> created by pkgsrc packages don't get the additional directories in
> their rpaths at link time, even though the link command includes the
> relevant rpath directives, and even though running the same link
> command manually in the same package's work directory yields an
> executable with the desired rpath.
>=20
> screen is a good example. If I run the following command in
> pkgsrc/misc/screen, the executable doesn't get the rpath I want:

pkgsrc wrappers remove it.

> [1] At any rate, I don't know of a good way to get the executables to
> use those libraries. Unlike the COMPAT_* emulations of other operating
> systems, it doesn't look like there's any magical pathname magic going
> on when running old native binaries on NetBSD; I don't know whether
> there's any version information in the binaries to indicate that a
> native binary is old. I'd prefer not to litter /usr/lib and
> /usr/X11R6/lib with symlinks, since eventually I won't need the old
> libraries any more. Wrapping some of the failing programs with scripts
> that set LD_LIBRARY_PATH can work, but there are some suid programs
> that I'd like to use (e.g., screen, minicom), and even for programs
> that can work this way, having old versions of the libraries in
> directories in LD_LIBRARY_PATH prevents running 2.0 binaries as
> subprocesses. Using rpaths seems to be an elegant solution, at any
> rate.

the easiest solution i can think of is to add /usr/pkg/emul/netbsd16 to
your /etc/ld.so.conf on 2.0_BETA hosts.


regards,

--=20
-- Lubomir Sedlacik <salo@{NetBSD,Xtrmntr,silcnet}.org>   --

--sXc4Kmr5FA7axrvy
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (NetBSD)

iD8DBQFBTLYXiwjDDlS8cmMRAr8YAJwMWdsCnLWt4Necmupw3WO1i/keQACfY9Lp
THiURoBz1xekzSGy3hYA+Uw=
=7w1b
-----END PGP SIGNATURE-----

--sXc4Kmr5FA7axrvy--