Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Feb 2019 10:50:40 -0800
From:      John Baldwin <jhb@FreeBSD.org>
To:        Brandon Bergren <freebsd@bdragon.rtk0.net>, "freebsd-toolchain@FreeBSD.org" <freebsd-toolchain@freebsd.org>
Subject:   Re: External GCC Update
Message-ID:  <3153f8b9-5873-8ff1-a63f-b57cab887556@FreeBSD.org>
In-Reply-To: <b8f8b304-d7af-4c53-82ac-ed4e9e6b78dc@www.fastmail.com>
References:  <e8d1431f-cf99-1986-7f23-6ff0f4cd8314@FreeBSD.org> <b8f8b304-d7af-4c53-82ac-ed4e9e6b78dc@www.fastmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2/22/19 6:03 PM, Brandon Bergren wrote:
> 
> 
> On Fri, Feb 22, 2019, at 1:01 PM, John Baldwin wrote:
>> I was recently able to install base/binutils and base/gcc into an amd64 VM
>> and do a self-hosted build and install.  Some of the port patches have been
>> committed from this, but I have some source patches before the final ports
>> patches can be finished.
>>
>> The source patches are here:
>> https://github.com/bsdjhb/freebsd/compare/master...base_gcc
>>
>> They do a couple of things I'd like some feedback on:
>>
>> 1) MK_GDB no longer depends on MK_BINUTILS so that /usr/libexec/gdb can
>>    still be built/installed when WITHOUT_BINUTILS=yes is true
> 
> Good thinking.
> 
>> 2) WITH_BASE_GCC and WITH_BASE_BINUTILS knobs can be set in src.conf to
>>    ensure that 'make delete-old' doesn't delete files installed by the
>>    base/* packages if you also set WITHOUT_BINUTILS=yes, and similar
>>    knobs (because you don't want to build/install the ones from src)
> 
> I was really confused about the naming when I read through the diff. Bikeshedding but I think WITH_PORTS_BASE_BINUTILS / WITH_PORTS_BASE_GCC would help quite a lot cognitively, to differentiate between "base as in in-tree binutils" and "base as in the base/binutils port"

In the future there won't be a "base as in in-tree binutils", only the
special ports from base/ that are used to build components of the base
system that come as packages, but I don't care strongly about the names.

>> 3) I add support for an /etc/src.conf.d dir that can hold files that get
>>    treated as if they are part of /etc/src.conf.  The current patch on
>>    github for this only fixes world and not yet kern.pre.mk and probably
>>    needs the most review if we want to go forward with this route.  With
>>    this, I plan to have the base/* packages install suitable files in this
>>    dir that disable build of the src-based components and also set
>>    WITH_BASE_<foo> to make sure 'delete-old' DTRT.
> 
> Not sure if I like this. Can't src.opts.mk just call `pkg info -e base/binutils` and so forth and use the exit result to adjust the defaults?

That requires src.opts.mk to encode the policy that each package wants to
enforce rather than letting the package choose the policy it wants to
enforce.  I think we want the latter.
 
>> The file for base/binutils would be:
>>
>> CROSS_BINUTILS_PREFIX=/usr/bin/
>> WITH_BASE_BINUTILS=yes
>> WITHOUT_BINUTILS=yes
>> WITHOUT_LLD_IS_LD=yes
>>
>> The file for base/gcc would be:
>>
>> XCC=/usr/bin/cc
>> XCXX=/usr/bin/c++
>> XCPP=/usr/bin/cpp
>> X_COMPILER_TYPE=gcc
>> WITH_BASE_GCC=yes
>> WITHOUT_GCC=yes
>> WITHOUT_CLANG_IS_CC=yes
> 
> I don't like the concept of packages messing with anything related to src.conf. I have a bunch of conditional stuff in mine broken out by ${TARGET_ARCH} and extra config suddenly appearing would break a lot of my cross compiling stuff, even if it is in a separate *.d folder.
> 
> Seems to me that just influencing src.opts.mk's defaults would be more robust.

Hmm, cross compiling is indeed a bear.  My original version of this was to
have base/gcc install a special 'freebsd-gcc.mk' toolchain file to
/usr/share/toolchains and modify Makefile.inc1 to use this as the default
CROSS_TOOLCHAIN if present.  I mostly didn't like this because it would be
a single file that so you can't set separate policy if, for example, some
arch or install only wanted base/binutils and not base/gcc.  On the other
hand, it had the advantage that setting an explicit CROSS_TOOLCHAIN when you
are cross compiling would work correctly.

Perhaps I can rework this to use two files in /usr/share/toolchains and have
Makefile.inc1 explicitly include any files in that directory if
CROSS_TOOLCHAIN isn't set?
-- 
John Baldwin

                                                                            



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3153f8b9-5873-8ff1-a63f-b57cab887556>