`Hiding' libc symbols

[Terry Lambert]

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