Renaming all symbols in libmp(3)

[David Schultz]

On Thu, Feb 26, 2009, Christoph Mallon wrote:
> David Schultz schrieb:
> >On Thu, Feb 26, 2009, Ed Schouten wrote:
> >>One of the reasons why we can't compile the base system yet, is because
> >>some applications in the base system (keyserv, newkey, chkey, libtelnet)
> >>won't compile, because a library they depend (libmp)on has a function
> >>called pow(). By default, LLVM has a built-in prototype of pow(),
> >>similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The
> >>manual page also mentions this issue.
> >
> >I think most apps that used to use libmp have transitioned to
> >libgmp, so I don't have much of an opinion on this change...
> >
> >However, if the compiler as a builtin for the math.h-style pow()
> >function, and the builtin causes it to choke even when math.h
> >isn't #included, that's a bug in the compiler. The people who are
> >proposing that we make the base system LLVM-compatible should be
> >more forceful in insisting that LLVM be fixed. ;-) What do the LLVM
> >folks propose to do about all the (perfectly legal) programs out
> >there that have a variable called 'exp'?
> 
> No, it's invalid code to have a function named pow() in a hosted 
> environment which is not /The/ pow().
> Having a *local* variable named exp is fine, because this declaration 
> shadows the function. A *global* variable on the other hand is not allowed.

The C standard makes no guarantees because it doesn't want to say
much about system libraries or how apps are actually linked, but
in practice people have found it very useful to do things like
link against libraries with special debugging versions of
malloc(), and in the past, developers have tried to ensure that
this continues to work. (You can find some old threads in the
archives.) Of course, people who do this need to take adequate
precautions (e.g., linking their programs in the right order,
using weak symbols where appropriate), but it does work, and it
would be nice if the compiler didn't break it.

As for gcc's math builtins, most of them are buggy. They fail to
respect the dynamic rounding mode, fail to generate exceptions
where appropriate, fail to respect FENV_ACCESS and other pragmas,
etc. Also, the complex builtins use simplified formulas that don't
get the right answers for complex numbers with inf/nan components.
Try running some of the tests in tools/regression/lib/msun without
-fno-builtin and see what happens ;-)