Renaming all symbols in libmp(3)

[Christoph Mallon]

David Schultz schrieb:
> 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

The C standard is very explicit which identifiers are reserved, see §7.1.3

> 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 ;-)

pow() is just an example.
The compiler may do magic with any call which has semantics defined by 
the C standard in a hosted environment.