Date: Tue, 20 Oct 2015 14:35:41 +0100 From: Andrew Turner <andrew@fubar.geek.nz> To: Jukka Ukkonen <jau789@gmail.com> Cc: Ian Lepore <ian@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: machine/acle-compat.h missing Message-ID: <20151020143541.5f6b8450@bender> In-Reply-To: <5625EA6D.3000305@gmail.com> References: <561B4A25.2030703@gmail.com> <20151012232952.GR67524@funkthat.com> <qdnhjn.nw50ar.1hge18i-qmf@smtp.gmail.com> <626A93AA-8E14-4027-8FFC-95CA2AC77193@kientzle.com> <59E5C236-908F-4AAA-942B-7E5FE5B76C0D@gmail.com> <1445186896.71631.57.camel@freebsd.org> <5625EA6D.3000305@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Oct 2015 10:17:01 +0300 Jukka Ukkonen <jau789@gmail.com> wrote: > On 10/18/15 19:48, Ian Lepore wrote: > > We need to be very clear here that the problem is the procedure you > > are using to build, and not anything with the build system or the > > compilers. I build arm 11 images on 10-stable every day, using the > > documented procedures (which certainly do NOT involve overriding CC > > and CXX), as do many other people. > > > > The first step of a build is to use the existing system compiler to > > build the latest compiler, which is then used to build the rest of > > the source. The default clang 3.4 on 10-stable has no problem > > building clang 3.7 as the first step of an arm build, and that > > clang 3.7 is then used to compile world and kernel. > > Right, since I fell back to using the default cc on 10-stable > I have kept getting very uninformative linker failed alerts > when trying to run parallel builds (-j N, where N > 1). > Eventually I decided to try a build with a single make job only, > though, it took all ages. Finally the compiler complaints were > a bit more informative. > For some reason there were first complaints about truncated > relocations (R_ARM_CALL and R_ARM_JUMP24) and only then the > linker failed message. For now I don't have the foggiest idea > how this could happen, but supposedly this explains the > mysterious linker failed complaint. One possibility which > I am going to test is whether -O3 is creating so large code > that it could be the root cause for the relocation overflows. > Previously -O3 was just fine, though. -O3 is not supported, it may work, or it may, as you have found, cause clang to increase in size such that it is too large to link. The issue is the distance between crt1.o (at the start of the file) and libc.a (near the end) is too far due to an increase in code between the two. Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151020143541.5f6b8450>