cvs commit: src/contrib/gcc/config freebsd-spec.h
ru at FreeBSD.org
Tue Sep 2 08:57:30 PDT 2003
> 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:
> > paprika# ldd /usr/X11R6/lib/libqt-mt.so
> > /usr/X11R6/lib/libqt-mt.so:
> > libmng.so.1 => /usr/local/lib/libmng.so.1 (0x287bc000)
> > ...
> > libc_r.so.5 => /usr/lib/libkse.so.1 (0x28b06000)
> > ...
> > 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.
> > 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.
Ruslan Ermilov Sysadmin and DBA,
ru at sunbay.com Sunbay Software Ltd,
ru at FreeBSD.org FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20030902/705c0a82/attachment-0001.bin
More information about the cvs-src