[RFC] external compiler support
Warner Losh
imp at bsdimp.com
Wed Feb 27 21:25:45 UTC 2013
On Feb 27, 2013, at 12:08 PM, Brooks Davis wrote:
> On Wed, Feb 27, 2013 at 09:08:05AM -0700, Warner Losh wrote:
>> Ooops, forgot to add one item..
>>
>>
>> On Feb 27, 2013, at 8:57 AM, Warner Losh wrote:
>>
>>>
>>> On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote:
>>>
>>>> Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) you
>>>> can find an initial patch with proposed commit for external compiler
>>>> support. It relies on the existing cross binutils as I'm finding that
>>>> the two are fairly separable. With this patch I've been able to build
>>>> from amd64 to arm, amd64, and i386 using clang from the lang/clang-devel
>>>> port. I've also compiled the tree with a customized clang being
>>>> developed at the University of Cambridge.
>>>
>>> Cool!
>>>
>>>> The patch is untested with gcc.
>>>
>>> I'd like to see it tested with gcc :)
>>>
>>>> Does this seem like a reasonable approach? I do plan to look at external
>>>> binutils support, but it's not on the critical path for our current work
>>>> so I've opted to avoid it for now.
>>>
>>> The patches I posted a few months ago had that as well...
>>>
>>>> As a bonus for those who don't need an external compiler, but do run
>>>> make buildworld frequently, the XCC, XCXX, and XCPP variables can be set
>>>> to the location of the installed base system compiler to avoid building
>>>> the compiler twice during buildworld.
>>>
>>> I think this will work, but it is kludgy. I had created a __X=<prefix-path> which was prepended to ${CC}, et al, in sys.mk. It was only defined when you set CROSS_COMPILER_PATH (or EXTERNAL_COMPILER_PATH, I forget) during the cross building stage. It also had the advantage of making external cross binutils available. Your patch could fairly easily use this interface instead of having to set 3 different variables, which will morph to 10 when you add binutil support.
>>
>
> I think something like this will have to be done for binutils given the
> way -B works, but I don't think it's workable in the general compiler
> case because I want to be able to use gcc46 or a future clang33 or
> similar as CC without changing the system compiler. Ideally I'd
> also like to support clang's method of finding appropriate binutils
> by looking first for /binutils/path/${TARGET_TRIPLE}-tool and then
> /binutils/path/tool.
I didn't know that clang did this, but that's certainly doable.
> As a strawman, let's say we add a CROSS_COMPILER_PATH and a
> CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if they
> are unset. The latter will control -B and set the various binutils
> variables (XNM, XLD, etc).
I'm not sure I like splitting things like that. It is unnatural.
> The sys.mk solution seems clean at first glance, but I don't think it's
> sufficently general. It's also insufficient because you need --sysroot
> unless you want to build a sysroot somewhere and hardcode paths to it
> into your toolchain. Worse, if you want rescue to work, --sysroot must
> be part of CC etc because crunchgen doesn't make it easy to manipulate
> CFLAGS.
Yes, that's a hole in the current system. My stuff works great for xdev-build toolchains, but less well for generic toolchains because of the sysroot issue. that's one part of your patch I especially liked.
>> I've also started looking into using clang --mumble to doing cross builds too, so I don't have to have 4 compilers configured and laying around for the different platforms I play with. That isn't reflected in the port.
>>
>
> I'm not sure what you mean by "That isn't reflected in the port".
s/port/patches/ will help. Basically, I did "CC?=${__X}cc" when I should have done "CC?=${__X}cc ${__Y}".
Warner
More information about the freebsd-arch
mailing list