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

[Mark Millard]

On 2016-Jan-19, at 12:20 PM, Ian Lepore <ian at freebsd.org> wrote:
> 
> On Tue, 2016-01-19 at 11:46 -0800, Mark Millard wrote:
>> 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?
> 
> We've been using clang 3.7 since October.  We never needed -mlong-calls
> until recently.  I had thought it was clang 3.8 that triggered the need
> for -mlong-calls, but now we apparently have a report of clang 3.7.x
> needing it.
> 
> So... why?  What changed, and why are we blindly reacting without
> understanding?
> 
> -- Ian

The initial report turned out to be for a build for /usr/src content from *after* the -mlong-calls had been added to 11.0-CURRENT.

I'm not sure that anything reported as a failure is from before the -mlong-calls were added to 11.0-CURRENT. Or from between -r293648 and -r294031 .

As far as I can tell people are just exploring trying to find some context difference that controls getting the different results. Having an explanation established before such an identification is also known is problematical.



It does not help that self-hosted builds on rpi2's and the like take so long. Bisecting has a long elapsed time. It would take several going in parallel on different -r?????'s to speed up that style of finding where things changed.

I do not remember any reports of a cross-build failure but it may be that most "on rpi2" folks do not also do cross builds so that little is known for that context.



I do not know what it takes to use clang/clang++ 3.7.1 but to also avoid the clang++ 3.7.1 Bus Errors that I got during buildworld on the rpi2. I'd have to solve that first before contributing to the "on rpi2" testing of 3.7.1-based builds. (Cross builds did not/do not have the Bus Error problem in clang++.)

My historically targeting cortex-a7 means that my past activity is of questionable applicability to the questions at play.

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