Re: Clang buildworld failure due to multiple definitions of __isnanf

On Sun, Jun 26, 2011, Eric McCorkle wrote:
> I've both seen reports and experienced make buildworld with clang 
> failing in usr.bin/xlint/lint1 (really, make kernel-toolchain is what 
> fails), because lint1 is statically linked, and there is a definition of 
> __isnanf in both libc and libm.  GCC, on the other hand, builds just fine.
> 
> The file tree.c in usr.bin/xlint/lint1 calls both isnan and finite from 
> math.h.  After some investigation, I figured out what's going on. 
> math.h includes a macro version of isnan, which expands out to an 
> expression that calls isnan, __isnanl, and __isnanf.  GCC seems to treat 
> all of these as builtin functions, and implements them with its code 
> generator, rather than generating calls.  Clang, on the other hand, does 
> not, which leaves calls to __isnanf in the resulting object file, which 
> will result in multiple definitions at link time.

__isnanf is in both libraries for compatibility reasons.  We can't
remove it from libc because some historical programs that don't
link against libm expect it to be there.  We might be able to
remove it from libm, but this would entail introducing a FBSD_1.2
version of the symbol in libc.

Does your toolchain support symbol versioning?  The libc symbol has
version FBSD_1.0, while the libm version is FBSD_1.2.

> A better solution, I think, is to modify math.h with something like this:
> 
> #ifdef __clang__
> #define isnan(n) __builtin_isnan(n)
> ...
> #endif

That breaks -fno-builtin, which is helpful sometimes (especially
when the compiler builtins are bogus.)  It also does nothing but
paper over the problem...

It would be nice to have a way to let the compiler use the builtin
version of isnan() if -fbuiltin is enabled.  The macro definitions
are needed when the builtin is disabled or doesn't exist, but they
have the unfortunate side-effect of preventing the builtin from
being used at all, even when it is available.