/usr/lib/libcompiler_rt.a (on stable/10 after 10.1) has the following undefined symbols, which are provided by libm: U fabs U fabsf U fabsl U fmax U fmaxf U fmaxl U logb U logbf U logbl U scalbn U scalbnf U scalbnl GCC's libgcc{.a,_s.so} intentionally avoids relying on external libm functionality. Presumably we haven't encountered an issue with this before for a few reasons: - static libgcc.a / libcompiler_rt.a is probably used much less often - the complex division routines that introduce these dependencies are probably not used often - code that would generate a call to the complex division routines likely links with -lm (although the link order might be wrong?) Here's a similar issue in Chromium: https://code.google.com/p/nativeclient/issues/detail?id=4019 This will be a problem if we want to use compiler-rt instead of libgcc_s.so. For reference, the other (non-math related) undef symbols are: U _GLOBAL_OFFSET_TABLE_ U __stack_chk_fail U __stack_chk_guard U __stderrp U abort U fflush U fprintf U mprotect U sysconf
Hi dim -- do you want to look at this bug now that clang 3.7.0 has been committed to the tree?
(In reply to Garrett Cooper,425-314-3911 from comment #1) > do you want to look at this bug now that clang 3.7.0 has been committed > to the tree? Sure, though I am not entirely sure what to do about it yet...
Well, our options are: - rework libcompiler_rt so it avoids these dependencies - make them available to libcompiler_rt And in searching now I found this four year old NetBSD thread discussing the same issue: https://mail-index.netbsd.org/tech-userlevel/2011/05/31/msg005126.html