Date: Wed, 20 Jan 2016 07:00:08 +0000 From: Tom Vijlbrief <tvijlbrief@gmail.com> To: Mark Millard <markmi@dsl-only.net>, Ian Lepore <ian@freebsd.org> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: make buildworld failed with error "relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'" Message-ID: <CAOQrpVf3VdoZ79V27Abue4GsCBgD-2KzmmotS6SB5%2BfO0d70Sw@mail.gmail.com> In-Reply-To: <36E4B4DD-C479-484D-8BA3-A1DC1F71564A@dsl-only.net> References: <3E1CC674-D534-4C33-8C96-CA9E584931C0@dsl-only.net> <569D2557.3060802@codeghar.com> <C9C41590-3798-45D2-8F47-2A5AB4AA137A@dsl-only.net> <374A0F64-E3FC-42F1-AC03-DF8F88269AEB@dsl-only.net> <569D2D63.8030301@codeghar.com> <FF2B458C-5776-4797-9056-4CAA8DFECC43@dsl-only.net> <CAOQrpVeWUHNUoXAF_ko9NwXQcCkfuZNNbpFAJHTGnY_p5uu5sg@mail.gmail.com> <1453217670.46848.83.camel@freebsd.org> <D058186F-3232-4215-96B9-E1A253F12CBE@dsl-only.net> <1453234839.46848.88.camel@freebsd.org> <36E4B4DD-C479-484D-8BA3-A1DC1F71564A@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Op di 19 jan. 2016 22:08 schreef Mark Millard <markmi@dsl-only.net>: > On 2016-Jan-19, at 12:20 PM, Ian Lepore <ian@freebsd.org> wrote: > > > > On Tue, 2016-01-19 at 11:46 -0800, Mark Millard wrote: > >> On 2016-Jan-19, at 7:34 AM, Ian Lepore <ian at freebsd.org> wrote: > >>> > >>> On Tue, 2016-01-19 at 11:58 +0000, Tom Vijlbrief wrote: > >>>> Op ma 18 jan. 2016 20:37 schreef Mark Millard < > >>>> markmi@dsl-only.net>: > >>>> > >>>>> > >>>>> If you can tolerate tracking the 3.8.0 project ( > >>>>> base/projects/clang380-import ) until 3.8.0 is moved into 11.0 > >>>>> -CURRENT you > >>>>> could find out that way if clang 3.8.0 behaves the same in your > >>>>> context. So > >>>>> far I've not come up with anything else > >>>> > >>>> > >>>> I am having exactly the same buildworld problem on my RPI which > >>>> used > >>>> to > >>>> build fine a week ago. > >>>> > >>>> Currently testing the clang380-import branch as suggested to see > >>>> if > >>>> the > >>>> problem persists. > >>> > >>> The most confusing thing about this whole thread (besides the lack > >>> of > >>> logs so we're just guessing what's going on) is why this problem is > >>> suddenly happening on clang 3.7.x (I guess it's 3.7.x here) when > >>> that > >>> has never been a problem before? We needed to add the long-call > >>> option > >>> when testing clang 3.8, but why do we suddenly need it on clang 3.7 > >>> that hasn't needed it for months? > >>> > >>> This very much has the feel of slapping a bandaid on something that > >>> needs a better diagnosis (there may be internal bleeding). If we > >>> don't > >>> understand why it's failing, it doesn't make sense to try to fix it > >>> with the "cure" for a different problem. (Maybe we never > >>> understood > >>> the clang 3.8 problem.) > >>> > >>> -- Ian > >> > >> The -mlong-calls were added to 11.0-CURRENT recently. > >> > >> -r293648: 2016-Jan-10 (head/lib/csu/arm/Makefile) > >> -r294031: 2016-Jan-14 (the rest added here) > >> > >> May be a problem/incompleteness in the handling -mlong-calls itself? > >> Are the above the right time frame for the problem starting for > >> 3.7.1? > > > > We've been using clang 3.7 since October. We never needed -mlong-calls > > until recently. I had thought it was clang 3.8 that triggered the need > > for -mlong-calls, but now we apparently have a report of clang 3.7.x > > needing it. > > > > So... why? What changed, and why are we blindly reacting without > > understanding? > > > > -- Ian > > The initial report turned out to be for a build for /usr/src content from > *after* the -mlong-calls had been added to 11.0-CURRENT. > > I'm not sure that anything reported as a failure is from before the > -mlong-calls were added to 11.0-CURRENT. Or from between -r293648 and > -r294031 . > > As far as I can tell people are just exploring trying to find some context > difference that controls getting the different results. Having an > explanation established before such an identification is also known is > problematical. > 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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOQrpVf3VdoZ79V27Abue4GsCBgD-2KzmmotS6SB5%2BfO0d70Sw>