> The reason the math libm has such a huge hunger seems to be a liberal
> use of float constants, like `0.0', `huge', `one', etc.  [...]  Much
> can be gained if the constants were made global.  Ideally, they'd be
> "global" to the math lib only, something which can conceivably be
> done when constructing a shared library, eg. by tagging those symbols
> to become "internalized" in the final `ld -Bshareable' run.

> Thoughts?

I've wanted similar things in the past, and I've done it by writing a
little program which bashes the symbol table in the .o file to achieve
the desired effect (which in my uses has usually been to turn a symbol
from global into local or vice versa, occasionally to bash its name by
modifying the string table).  Is there some reason to avoid such a
solution here, some reason why the solution would have to be part of
ld?  I've read over a.out(5) and feel sure I could get my
localize-a-symbol program working easily enough, so that one could do
something like

	cc -pic ... foo.c
	cc -pic ... bar.c
	...
	ld -x -r -o all-libm.o foo.o bar.o ...
	localize-symbol all-libm.o _libm_zero _libm_huge _libm_one ...
	ld -Bshareable ... all-libm.o

Assuming, of course, that ld -x -r doesn't destroy the PICness of the
.o files it merges.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu

------------------------------------------------------------------------------