Bug 200335
| Summary: | libcompiler_rt depends on libm symbols | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Ed Maste <emaste> |
| Component: | misc | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | New --- | ||
| Severity: | Affects Only Me | CC: | dim, ngie |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
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 |
/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