I did not think this would happen so soon.

Compiling the current version of libm into a shared library on the sparc
causes the Global Offset Table to overflow. gcc generates code to address
GOT entries with 13 bits (signed) offsets, which means that the table
can be have no more than 2048 entries. Currently, ld further restricts
the offset to positive numbers only, making the max # entries 1024.

I can probably fix ld to "center" the GOT so all 2048 entries are accessible
(if this is not enough, you could compile with `-fPIC' in stead if `-fpic',
but this also needs additional support from ld).

Until this is sorted out, do not use a shared libm on the sparc.

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. These are all compiled
into static storage by gcc, and cause a GOT entry to be allocated when
generating PIC code. Even when ld is fixed, the overhead of run-time
relocation remains (this holds true for other machine architectures as well).
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?

-pk


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