From owner-freebsd-toolchain@freebsd.org Fri Jan 22 01:18:18 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D957DA8CD02 for ; Fri, 22 Jan 2016 01:18:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 889621E0F for ; Fri, 22 Jan 2016 01:18:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1295 invoked from network); 22 Jan 2016 01:18:10 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 22 Jan 2016 01:18:10 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Thu, 21 Jan 2016 20:18:12 -0500 (EST) Received: (qmail 27452 invoked from network); 22 Jan 2016 01:18:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 22 Jan 2016 01:18:12 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4A7E01C43C1; Thu, 21 Jan 2016 17:18:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: make buildworld failed with error "relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'" From: Mark Millard In-Reply-To: <1870E0DF-2EF5-4A04-A994-95E4F1D5F754@bsdimp.com> Date: Thu, 21 Jan 2016 17:18:08 -0800 Cc: freebsd-arm , FreeBSD Toolchain , Andrew Turner Content-Transfer-Encoding: quoted-printable Message-Id: References: <358D5606-3B91-4050-9BE4-CF3E23A253E5@dsl-only.net> <1870E0DF-2EF5-4A04-A994-95E4F1D5F754@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 01:18:19 -0000 On 2016-Jan-21, at 3:39 PM, Warner Losh wrote: >=20 >> On Jan 21, 2016, at 2:41 PM, Mark Millard = wrote: >>=20 >> On Thu Jan 21 13:11:03 UTC 2016 Andrew Turner andrew at fubar.geek.nz = wrote" >>=20 >>> 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. >>=20 >>=20 >> 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: >>=20 >> BEAGLEBONE >> CUBOX-HUMMINGBOARD >> GUMSTIX >> RPI-B >> PANDABOARD >> WANDBOARD >>=20 >> 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). >>=20 >> 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). >=20 > Personally, I think we should make the dependent on the compiler = version when we bring them back / before we MFC things. >=20 > 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. =46rom what I see only one of the arm -mlong-calls was removed by = -r294499: > Modified: head/lib/clang/clang.lib.mk > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- 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=3D ${.CURDIR}/../../../contrib/l > INTERNALLIB=3D > =20 > .if ${MACHINE_CPUARCH} =3D=3D "arm" > -STATIC_CXXFLAGS+=3D -mlong-calls > +# This will need to be enabled to link clang 3.8 > +#STATIC_CXXFLAGS+=3D -mlong-calls > .endif > =20 > .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. =3D=3D=3D Mark Millard markmi at dsl-only.net