make buildworld failed with error "relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'"

Mark Millard markmi at dsl-only.net
Tue Jan 19 19:46:54 UTC 2016


On 2016-Jan-19, at 7:34 AM, Ian Lepore <ian at freebsd.org> wrote:
> 
> On Tue, 2016-01-19 at 11:58 +0000, Tom Vijlbrief wrote:
>> Op ma 18 jan. 2016 20:37 schreef Mark Millard <markmi at dsl-only.net>:
>> 
>>> 
>>> If you can tolerate tracking the 3.8.0 project (
>>> base/projects/clang380-import ) until 3.8.0 is moved into 11.0
>>> -CURRENT you
>>> could find out that way if clang 3.8.0 behaves the same in your
>>> context. So
>>> far I've not come up with anything else
>> 
>> 
>> I am having exactly the same buildworld problem on my RPI which used
>> to
>> build fine a week ago.
>> 
>> Currently testing the clang380-import branch as suggested to see if
>> the
>> problem persists.
> 
> The most confusing thing about this whole thread (besides the lack of
> logs so we're just guessing what's going on) is why this problem is
> suddenly happening on clang 3.7.x (I guess it's 3.7.x here) when that
> has never been a problem before?  We needed to add the long-call option
> when testing clang 3.8, but why do we suddenly need it on clang 3.7
> that hasn't needed it for months?
> 
> This very much has the feel of slapping a bandaid on something that
> needs a better diagnosis (there may be internal bleeding).  If we don't
> understand why it's failing, it doesn't make sense to try to fix it
> with the "cure" for a different problem.  (Maybe we never understood
> the clang 3.8 problem.)
> 
> -- Ian

The -mlong-calls were added to 11.0-CURRENT recently.

-r293648: 2016-Jan-10 (head/lib/csu/arm/Makefile)
-r294031: 2016-Jan-14 (the rest added here)

May be a problem/incompleteness in the handling -mlong-calls itself? Are the above the right time frame for the problem starting for 3.7.1?

The "rest" were:

head/lib/clang.lib.mk
head/lib/libc++/Makefile
head/usr.bin/clang/clang/Makefile
head/usr/bin/clang/lldb/Makefile

(head/share/mk/bsd.lib.mk has had use of STATIC_CFLAGS and STATIC_CXXFLAGS for a long time.)


Since 3.8.0 is now also to reported to fail I'll note that my "on rpi2" rebuild test was based on 3.8.0 and -r294179 for /usr/src and completed fine (in about 10 minutes under 14.5 hours). But I've consistently used:

-target armv6--freebsd11.0-gnueabi -march=armv7a -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access

in my builds, including that one. So my activities are really a test for cortex-a7 handling, not armv6.

But I had to use 3.8.0 because clang++ 3.7.1 would Bus Error during its buildworld activities. (I could buildkernel with 3.7.1 just fine.)

===
Mark Millard
markmi at dsl-only.net



More information about the freebsd-arm mailing list