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"
