> On Mar 31, 2015, at 1:43 PM, Craig Rodrigues <rodr...@freebsd.org> wrote: > > On Tue, Mar 31, 2015 at 1:41 PM, Dimitry Andric <d...@freebsd.org> wrote: > >> On 31 Mar 2015, at 22:06, Craig Rodrigues <rodr...@freebsd.org> wrote: >>> >>> On Tue, Mar 31, 2015 at 12:48 PM, Dimitry Andric <d...@freebsd.org> >> wrote: >>> On 31 Mar 2015, at 21:38, Craig Rodrigues <rodr...@freebsd.org> wrote: >>>> >>>> On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric <d...@freebsd.org> >> wrote: >>>> >>>>> On 31 Mar 2015, at 20:13, Dimitry Andric <d...@freebsd.org> wrote: >>>>> ... >>>>>> but then: >>>>>> >>>>>> + patch >>>>>> Hmm... Looks like a unified diff to me... >>>>>> The text leading up to this was: >>>>>> -------------------------- >>>>>> |Index: contrib/libc++/include/type_traits >>>>>> |=================================================================== >>>>>> |--- contrib/libc++/include/type_traits (revision 280762) >>>>>> |+++ contrib/libc++/include/type_traits (working copy) >>>>>> -------------------------- >>>>>> Patching file contrib/libc++/include/type_traits using Plan A... >>>>>> Reversed (or previously applied) patch detected! Assume -R? [y] >>>>>> Hunk #1 succeeded at 842. >>>>>> Hunk #2 succeeded at 877. >>>>>> Hmm... Ignoring the trailing garbage. >>>>>> done >>>>>> >>>>>> E.g., it undoes the change to type_traits that was merged in the >>>>> subversion update. >>>>> >>>>> >>>> OK, I undid the patch. Now the clang and libc++ parts build, but I'm >>>> still getting problems building rescue: >>>> >>>> >> https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/29/console >>> >>> Hm, that is strange. I have just completed a build with >>> amd64-xtoolchain-gcc, and apart from boot2, everything worked... >>> >>> What does readelf say when you run it on the cat.lo file which is >>> complained about in the log? And what happens if you delete it, and >>> restart the build? >>> >>> See: >>> >> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001545.html >> >> I'm suspecting this might have something to do with crunchide, or least, >> the copy of crunchide that is run for this: >> >> --- cat.lo --- >> /usr/local/x86_64-freebsd/bin/ld -dc -r -o cat.lo cat_stub.o >> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue//builds/FreeBSD_HEAD_external_toolchain_gcc/bin/cat/cat.o >> crunchide -k _crunched_cat_stub cat.lo >> >> If I look at my own build logs, it seems to pick the crunchide >> executable in /usr/bin, and Makefile.inc1 does *not* build it during the >> cross-tools stage if ${TARGET_ARCH} is the same as ${MACHINE_ARCH}: >> >> .if ${TARGET_ARCH} != ${MACHINE_ARCH} >> .if ${MK_RESCUE} != "no" || defined(RELEASEDIR) >> _crunchide= usr.sbin/crunch/crunchide >> .endif >> >> However, this does not explain why my /usr/bin/crunchide seems to not >> screw up cat.lo, while yours does. As far as I can see, we're both >> building this on a stable/10 amd64 box... >> > >> Maybe, as a hack, you can force cross-tools to build crunchide, by >> patching Makefile.inc1 to ignore the arch check, and see what that >> results in? >> > > > > Well my build host is 10.1-RELEASE, so maybe there are changes > that went into 10-STABLE after 10.1 that prevent this from working. > > I'll give a shot at hacking things and let you know how far I get.
BTW, we don’t officially support 4.8 / 4.9 yet. There are things that are known to be broken with it, and since we don’t tinderbox it, it is likely that we’ll break it over and over again… When I was building it, as a test, I used WITHOUT_RESCUE. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
