On 2016-Jan-21, at 3:39 PM, Warner Losh <i...@bsdimp.com> wrote: > >> On Jan 21, 2016, at 2:41 PM, Mark Millard <mar...@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 _______________________________________________ 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"