Bug 200335 - libcompiler_rt depends on libm symbols
Summary: libcompiler_rt depends on libm symbols
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-19 17:29 UTC by Ed Maste
Modified: 2015-10-16 20:56 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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