Date: Wed, 20 Jan 2016 11:21:00 +0100 From: Michal Meloun <mmel@freebsd.org> To: freebsd-arm@freebsd.org Subject: Re: make buildworld failed with error "relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'" Message-ID: <569F5F8C.1070509@freebsd.org> In-Reply-To: <569F5180.50909@freebsd.org> References: <569F5180.50909@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dne 20.01.2016 v 8:00 Tom Vijlbrief napsal(a): > 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. > >> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?569F5F8C.1070509>