Bug 200335

Summary: libcompiler_rt depends on libm symbols
Product: Base System Reporter: Ed Maste <emaste>
Component: miscAssignee: freebsd-bugs mailing list <bugs>
Status: New ---    
Severity: Affects Only Me CC: dim, ngie
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   

Description Ed Maste freebsd_committer 2015-05-19 17:29:54 UTC
/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
Comment 1 Enji Cooper freebsd_committer 2015-10-16 00:15:40 UTC
Hi dim -- do you want to look at this bug now that clang 3.7.0 has been committed
to the tree?
Comment 2 Dimitry Andric freebsd_committer 2015-10-16 20:00:47 UTC
(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...
Comment 3 Ed Maste freebsd_committer 2015-10-16 20:56:04 UTC
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