Re: make buildworld failed with error "relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'"
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'"
> 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
make buildworld failed with error "relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'"
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). === 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'"
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"
make buildworld failed with error "relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'"
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"