> On Apr 3, 2015, at 10:58 AM, Craig Rodrigues <rodr...@freebsd.org> wrote:
> 
> On Thu, Apr 2, 2015 at 8:27 AM, Craig Rodrigues <rodr...@freebsd.org> wrote:
> 
>> 
>> Actually, I am building on a 10.1-RELEASE box.
>> 
>> I was able to get this successful build:
>> 
>> https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/38/console
>> 
>> by applying this  patch (the ${TARGET_ARCH} != ${MACHINE_ARCH} checks
>> seemed wrong to me):
>> 
>> Index: Makefile.inc1
>> ===================================================================
>> --- Makefile.inc1       (revision 280979)
>> +++ Makefile.inc1       (working copy)
>> @@ -1457,12 +1457,9 @@
>> # we get done with the earlier stages. It is the last set of tools needed
>> # to begin building the target binaries.
>> #
>> -.if ${TARGET_ARCH} != ${MACHINE_ARCH}
>> .if ${TARGET_ARCH} == "amd64" || ${TARGET_ARCH} == "i386"
>> _btxld=                usr.sbin/btxld
>> .endif
>> -.endif
>> -.if ${TARGET_ARCH} != ${MACHINE_ARCH}
>> .if ${MK_RESCUE} != "no" || defined(RELEASEDIR)
>> _crunchide=    usr.sbin/crunch/crunchide
>> .endif
>> @@ -1469,7 +1466,6 @@
>> .if ${TARGET_ARCH} == "i386" && defined(RELEASEDIR)
>> _kgzip=                usr.sbin/kgzip
>> .endif
>> -.endif
>> 
>> # If we're given an XAS, don't build binutils.
>> .if ${XAS:M/*} == ""
>> 
>> 
> 
> I backed out this patch from my tree, and rebuilt everything
> in my 10.1-RELEASE VM from the latest CURRENT sources.  At this
> point, I ran into the same problem building rescue which I reported in
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001545.html
> 
> I put the patch back in my tree, and recompiled everything, and the
> problem went away.
> 
> To reliably build the tree, I think this patch should go in, so that these
> tools are properly bootstrapped during the build.

That shows that something in the list is needed. Likely only crunchhide.

It doesn’t tell us why we need it, or when we started needing it, or what
other conditions we might need it. This information is critical to document
so we know when we can stop doing it in the future. I’m extremely reluctant
to commit this until we know these details.

Sorry for being a bit of a pain about this, but these lists are something that
I’ll be maintaining long into the future and we’ve had issues in the past
where people would just hack something in and not document, then lovingly
copy it over and over w/o understanding :(

Warner

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to