Date: Mon, 05 May 2003 21:31:32 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Dag-Erling Smorgrav <des@ofug.org> Subject: Re: `Hiding' libc symbols Message-ID: <3EB73AA4.ADDDE95@mindspring.com> References: <Pine.GSO.4.10.10305051821380.3867-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > If libc also doesn't have any strong symbols (at least for > the functions you want to check), then I suppose you can > check the linked application for these (strong) definitions. > I don't know how to do it myself, but this may give you some > idea. There's really no way to do it. Even with strong symbols; the ones that get linked first "win", and any later references lose. The relocation isn't seperate enough to allow relinking the libc into a .o file (via ld -r). Maybe the answer is to put "/usr/lib/libc.a" on the linker line, instead of "-L/usr/lib -llibc"; even then, it might not work unless you forced the symbol import, and "ld -r"'ed the libc.a into a libc.o, to conver the types. Bottom line: it's a pretty bad idea, and most of the problems are coming from functions that are not in any ratified standard in the first place, which iw why the ports are carrying them around themselves (in the expectation that they will not be present in the host OS). Overriding libc symbols that *are* defined by a standard has a long and glorious history. It's the same one that says that preventing people from doing stupid things also prevents them from doing clever things. Personally, I'd be much happier with the "nm"-based symbol collision checker, whose results were recently posted, being made available in ports, so that ports maintainers who care can check for themselves, and provide patches to their ports to pluck out the offensive symbols: if thine symbols offend thee, pluck them out, oh port maintainer... -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EB73AA4.ADDDE95>