Date: Sat, 16 Oct 1999 08:07:23 +1000 From: John Birrell <jb@cimlogic.com.au> To: Wilko Bulte <wilko@yedi.iaf.nl> Cc: current@freebsd.org Subject: Weak symbols (Was: World breakage in libc_r?) Message-ID: <19991016080722.E67481@freebsd1.cimlogic.com.au> In-Reply-To: <199910151809.UAA63994@yedi.iaf.nl>; from Wilko Bulte on Fri, Oct 15, 1999 at 08:09:57PM %2B0200 References: <199910142225.SAA06440@pcnet1.pcnet.com> <199910151809.UAA63994@yedi.iaf.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 15, 1999 at 08:09:57PM +0200, Wilko Bulte wrote: > Sheer curiosity and most likely a somewhat dim question: > > what the h* is a weak versus a strong symbol? A weak symbol is like an alias for another (strong) symbol. The linker will link to strong symbols first, then, for any unresolved references, it will try to resolve against the weak symbols before going on to the next library. Weak symbols are a good way to hide things in order to stop polluting the name space. But they can cause problems too. Our use of weak symbols in libc is incomplete. Although syscalls like read() have _read() as the strong symbol and read() as the weak one, we continue to call read() in other areas of libc. This means that a user can create their own read() function and they won't get a clash when they link against libc, but other functions in libc that really want to call the _read() syscall will call the user's read() function instead. That's broken. We really need to change libc in the way that NetBSD did with their namespace.h stuff. This ensures that the internals of libc call the hidden names, not the weakly exported ones. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991016080722.E67481>