Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Sep 2003 18:57:18 +0300
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        Daniel Eischen <deischen@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/contrib/gcc/config freebsd-spec.h
Message-ID:  <20030902155718.GD64892@sunbay.com>
In-Reply-To: <Pine.GSO.4.10.10309020722030.25164-100000@pcnet5.pcnet.com>
References:  <Pine.NEB.3.96L.1030901232042.73191C-100000@fledge.watson.org> <Pine.GSO.4.10.10309020722030.25164-100000@pcnet5.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--SFyWQ0h3ruR435lw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> On Tue, 2 Sep 2003, Robert Watson wrote:
[...]
> > The effect I'm most interested in "getting right" at this point has to =
do
> > with library dependencies in third party applications.  Right now, when=
 we
> > build QT on FreeBSD, the resulting library has an explicit dependency on
> > libc_r:
> >=20
> > paprika# ldd /usr/X11R6/lib/libqt-mt.so
> > /usr/X11R6/lib/libqt-mt.so:
> >         libmng.so.1 =3D> /usr/local/lib/libmng.so.1 (0x287bc000)
> > ...
> >         libc_r.so.5 =3D> /usr/lib/libkse.so.1 (0x28b06000)
> > ...
> >=20
> > On my notebook, I use libmapl.conf to rewrite the dependency such that =
KSE
> > is used.  I think it's very important that we avoid a situation where, =
if
> > there are potential future changes in threading libraries, we find
> > binaries dependent on various threading libraries.  I'd like to see a
> > dependency on a single name, with a way to substitute that name.  I.e.,
> > all libraries dependent on a threading library, unless explicitly
> > configured otherwise, should be linked against a single common library.
> >=20
> > Otherwise, if we wipe out libc_r someday, or remove the 1:1 version of =
KDE
> > and decide M:N is the one true way, we'll leave users up a creek.

If the idea is to always have binaries internally linked to one name,
that could be tricky.  The problem is that linker takes an internal
name of the library from the library's binary, so if you link against
-lfoo, and /usr/lib/foo.so -> /usr/lib/bar.so, bar.so is what will
be written into a binary.  We've been through this already with
libtermcap -> libncurses.


Cheers,
--=20
Ruslan Ermilov		Sysadmin and DBA,
ru@sunbay.com		Sunbay Software Ltd,
ru@FreeBSD.org		FreeBSD committer

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/VL3dUkv4P6juNwoRAv6hAJ4+iwuy7LEoH22fsuW2NwAslG+MygCgjUba
VbeOcD4iEjVCpnn68DBBe0M=
=AeUm
-----END PGP SIGNATURE-----

--SFyWQ0h3ruR435lw--



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