CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

Warner Losh imp at bsdimp.com
Wed Apr 1 00:09:24 UTC 2015


> On Mar 31, 2015, at 1:43 PM, Craig Rodrigues <rodrigc at FreeBSD.org> wrote:
> 
> On Tue, Mar 31, 2015 at 1:41 PM, Dimitry Andric <dim at freebsd.org> wrote:
> 
>> On 31 Mar 2015, at 22:06, Craig Rodrigues <rodrigc at FreeBSD.org> wrote:
>>> 
>>> On Tue, Mar 31, 2015 at 12:48 PM, Dimitry Andric <dim at freebsd.org>
>> wrote:
>>> On 31 Mar 2015, at 21:38, Craig Rodrigues <rodrigc at FreeBSD.org> wrote:
>>>> 
>>>> On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric <dim at freebsd.org>
>> wrote:
>>>> 
>>>>> On 31 Mar 2015, at 20:13, Dimitry Andric <dim at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-testing/attachments/20150331/41a71c66/attachment.sig>


More information about the freebsd-testing mailing list