On Wed, Aug 16, 2006 at 01:05:26PM +0200, Jeremie Le Hen wrote: > Hi, > > On Fri, Aug 04, 2006 at 11:20:50AM +0300, Kostik Belousov wrote: > > Old build of the application linked against libc.so.6 and libthr.so.2. > > References to symbols in libthr.so.2 are satisfied by default > > version of the symbols. > > > > Missing are two things: > > > > 1. libpthread/libthr are still not linked against libc (as well as most > > shared libraries). Correspondingly, version information for referenced > > libc symbols is absent in the shared libraries. > > What does exactly prevent from linking shared libraries against libc ? > In this post [1] Warner Losh states that doing so would solve some > problems (probably the one we are talking about, albeit firefox-bin being > linked against libc.so.6 would conflict with libthr.so.2 being linked > against libc.so.7 -- how rtld(1) would handle this ?), but it will > also create so problems. What are they ? > > [1] http://lists.freebsd.org/pipermail/freebsd-hackers/2006-April/016143.html > > I've added Warner in the Cc: list. As I understand, the current state of not linking dso with libc comes from the time of RELENG_4. There are (were) two libc's: libc and libc_r. Since both libraries provide same symbols, existence of them in one image would cause the havoc. Dso cannot know in advance, whether the final image would use libc or libc_r (the only exception is dso that uses threads by itself). As result, no -lc for dso. Moreover, when the -lc switch somehow slipped in (I remember this for libGL.so), it causes huge problems with threaded programs that tried to use that dso. The current way of linking simply have not changed since then. For real symbol versioning support, linking with libc is the must. And, now this is possible due to single libc and separation of libpthread/libthr into separate dso. Resulting system will be much stricter with respect to mixing dso's from old-libc system and new one. This is never was supported, but, for instance, x11 libraries compiled on RELENG_6, can by used on CURRENT without much problems. After that change, no such frivolous mixing will ever work for bumped libraries version.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:59 UTC