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

[Warner Losh]

> On Jan 21, 2016, at 2:41 PM, Mark Millard  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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 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  wrote:
> 
>> On Jan 21, 2016, at 2:41 PM, Mark Millard  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 

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
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

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

[Tom Vijlbrief]

On my RPI-B I am currently testing:

cd /usr/src/lib/csu/arm
make clean install

Before the regular buildworld...

Op do 21 jan. 2016 01:17 schreef Mark Millard :

>
> Wed Jan 20 10:29:06 UTC 2016 Michal Meloun wrote:
>
> > Dne 20.01.2016 v 8:00 Tom Vijlbrief napsal(a):
> > . . .
> > >
> > > The buildworld on the RPI failed:
> > >
> > > http://www.v7f.eu/public/freebsd/world371.log
> > >
> > > The same tree build ok when cross compiling. I can supply the log if
> needed.
> > >
> > > My previous succesfull build on the RPI was jan 14, just before the
> > > introduction of the long-call flag for clang but after the long-call
> change
> > > for crt1.o on jan 10th.
> > >
> > > Could this partial introduction of the long-call flag in the installed
> > > world be the cause of the issue? I would expect a buildworld to use
> only
> > > libs from /usr/obj but the failing link refers to /usr/lib.
> > >
> > > I will try installing the new cross compiled world to see if that
> fixes the
> > > native build.
> > >
> > >>
> > > ___
> > > freebsd-arm at freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at
> freebsd.org"
> > >
> >
> > Confirmed. Native build of fresh current fails on bootstrap clang link
> > phase.
> >
> > The bootstrap clang is now build with -mlong-calls and is significantly
> > longer that previous one (without -mlong-calls). Also, bootstrap clang
> > is linked with original "/usr/lib/crti.o" (which is compiled without
> > -mlong-calls), so link fails.
> >
> > This is also reason, why the problem is not seen with crossbuild  -
> > bootstrap clang is builded for host architecture and final (target)
> > clang is linked with right (new, compiled with -mlong-calls) crti.o.
> >
> > Michal
>
>
> For on-arm buildworld with clang/clang++ (self hosted) . . .
> (Warning that I've not tried the below.)
>
> It appears that one can back out the -mlong-calls additions and get back
> to something that builds and installs without needing any cross builds from
> a different type of host.
>
> Going the other way: If one already has clang/clang++ 3.7.1 one does not
> need WITH_CLANG_BOOTSTRAP= involved as the existing system clang/clang++
> can already do the compiles.
>
> So try an explicit WITHOUT_CLANG_BOOTSTRAP= to avoiding having a version
> built that ends up linked with /usr/lib/crti.o (that is not based on
> -mlong-calls yet) but mixed that with having the -mlong-calls in place for
> the non-bootstrap clang build to use.
>
> The above might be a workaround sufficient for bootstrapping into a
> -mlong-calls based environment when the arm itself is to build clang and/or
> lldb.
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
>
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"