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

[Mark Millard]

On 2016-Jan-21, at 3:39 PM, Warner Losh <imp at bsdimp.com> wrote:
> 
>> On Jan 21, 2016, at 2:41 PM, Mark Millard <markmi at dsl-only.net> wrote:
>> 
>> On Thu Jan 21 13:11:03 UTC 2016 Andrew Turner andrew at fubar.geek.nz wrote"
>> 
>>> I've disabled setting -mlong-calls on the clang libraries for now,
>>> however I expect we will need to enable it again when clang 3.8.0 is
>>> imported. As such I would recommend anyone wishing to run buildworld on
>>> arm to update before this is imported.
>> 
>> 
>> It seems that folks that later progress from 10.x-??? (or before) to 11.0-RELELASE at some point for arm elf-hosted buildworld activity will face the issue without having the opportunity to build a -mlong-calls enabled context with a smaller clang first:
>> 
>> BEAGLEBONE
>> CUBOX-HUMMINGBOARD
>> GUMSTIX
>> RPI-B
>> PANDABOARD
>> WANDBOARD
>> 
>> So does the "all but clang libraries" -mlong-calls use need to be MFC'd? Even this may require updating from older 10.x's to a 10.y that has those -mlong-calls in place before going to 11.0-RELEASE (or later).
>> 
>> A similar point will be an issue for switching from such a 10.x (or before) to 11.0-CURRENT once clang 3.8.0 has been imported: it may require a middle stage of switching to a then-older 11.0-CURRENT first (such as -r294499).
> 
> Personally, I think we should make the dependent on the compiler version when we bring them back / before we MFC things.
> 
> Warner

As I understand the investigation results: the live system's /usr/lib/crt1.o (for example) must already have long-call support built in in order to then build (link) clang 3.8.0 in the normal sequencing of things.

A similar point may apply for the live /usr/lib/libc++.a content --at least if lldb is also part of the attempted build.



From what I see only one of the arm -mlong-calls was removed by -r294499:

> Modified: head/lib/clang/clang.lib.mk
> ==============================================================================
> --- head/lib/clang/clang.lib.mk	Thu Jan 21 12:42:31 2016	(r294498)
> +++ head/lib/clang/clang.lib.mk	Thu Jan 21 12:59:54 2016	(r294499)
> @@ -7,7 +7,8 @@ LLVM_SRCS= ${.CURDIR}/../../../contrib/l
>  INTERNALLIB=
>  
>  .if ${MACHINE_CPUARCH} == "arm"
> -STATIC_CXXFLAGS+= -mlong-calls
> +# This will need to be enabled to link clang 3.8
> +#STATIC_CXXFLAGS+= -mlong-calls
>  .endif
>  
>  .include <bsd.lib.mk>

The other arm -mlong-calls are all still in place:

head/lib/csu/arm/Makefile
head/lib/libc++/Makefile
head/usr.bin/clang/clang/Makefile
head/usr/bin/clang/lldb/Makefile

This allows getting to the state of the live system's /usr/lib/crt1.o (for example) and /usr/lib/libc++.a content already having long-call support before attempting a build of clang 3.8.0.

I'm not sure how one would test compiler versions to achieve such an overall sequencing that has proper live-system content at the right time. It is too bad that the requirement for the live-system is involved: only depending on /usr/obj/ content would simplify the sequencing requirements by removing the live-system requirement.


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