Date: Mon, 21 Aug 2000 10:59:19 -0500 From: "Jacques A. Vidrine" <n@nectar.com> To: freebsd-arch@freebsd.org Subject: Is it time yet? [was Re: Weak symbols] Message-ID: <20000821105919.A25903@hamlet.nectar.com> In-Reply-To: <19991016080722.E67481@freebsd1.cimlogic.com.au>; from jb@cimlogic.com.au on Sat, Oct 16, 1999 at 08:07:23AM %2B1000 References: <199910142225.SAA06440@pcnet1.pcnet.com> <199910151809.UAA63994@yedi.iaf.nl> <19991016080722.E67481@freebsd1.cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 16, 1999 at 08:07:23AM +1000, John Birrell wrote:
> 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.
Any compelling reason not do to this? I'm willing to do the (apparently
grunt) work. I would use the same approach as NetBSD, basically:
1) namespace.h would use the preprocessor to rename our public symbols
so that they begin with an underscore, e.g.
#define warnx _warnx
2) add __weak_alias for each symbol in the files in which they are
defined, e.g.
__weak_alias(warnx, _warnx);
in err.c
I'd like to hear if anyone has better suggestions, though.
Oh, yeah, Why do this? Well, John's description above is a good
reason. But also I bumped my head on this with a statically compiled
executable that wanted to define their own `warn', but pulled in a
libc function that referenced the `warn' in our `err.c'.
Cheers,
--
Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000821105919.A25903>