Date: Tue, 19 May 2015 17:29:54 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 200335] libcompiler_rt depends on libm symbols Message-ID: <bug-200335-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200335 Bug ID: 200335 Summary: libcompiler_rt depends on libm symbols Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: freebsd-bugs@FreeBSD.org Reporter: emaste@freebsd.org /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 -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-200335-8>