Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Aug 2018 15:22:54 +0100
From:      Alexander Richardson <arichardson@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        John Baldwin <jhb@freebsd.org>, "O. Hartmann" <o.hartmann@walstatt.org>,  FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
Message-ID:  <CA%2BZ_v8qrFvN58cmwyHjTxsbUYRWtOUyw5Qmp=hu8r6mZGMvVoQ@mail.gmail.com>
In-Reply-To: <CANCZdfrksNyccyo5DrnU4xtnFNu7-G5NOr22HkgJ9f1qiXH6zQ@mail.gmail.com>
References:  <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> <20180820220103.3ac8a3ac@thor.intern.walstatt.dynvpn.de> <6040ed15-143f-9a6d-8f37-b25a7e2d2036@FreeBSD.org> <CANCZdfpyzt_71aw3e-bAU35vtCA_TApx7-DaFJaL56bcRQonJQ@mail.gmail.com> <CA%2BZ_v8paRAQk=tJrWO_J6sp41uZ5q5ztiU67XpavUEY_Ae0cuw@mail.gmail.com> <CANCZdfpFD=aWALvk7r9LmemWUUr=KdEdXLY-3PUGEg5g22fHEA@mail.gmail.com> <CANCZdfrksNyccyo5DrnU4xtnFNu7-G5NOr22HkgJ9f1qiXH6zQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I think relaxing the check to just avoid includes of "${SRCTOP}/sys" is
probably the best solution. It would be nice to also handle the
${.CURDIR}/../../sys case but since it's just there to prevent ABI issues
that's probably fine.

Alex

On Tue, 21 Aug 2018 at 15:19 Warner Losh <imp@bsdimp.com> wrote:

> On Tue, Aug 21, 2018 at 8:16 AM, Warner Losh <imp@bsdimp.com> wrote:
>
>> There's a half a dozen special targets, however. clean comes to mind...
>>
>>
>> However, this test is needlessly restrictive:
>>
>> .if
>> !empty(CFLAGS:M*${SRCTOP}/sys*:N*${SRCTOP}/sys/cddl/compat*:N*${SRCTOP}/sys/crypto*)
>>
>> since it matches
>>
>> CFLAGS+=-I${SRCTOP}/sys/sys/disk
>>
>> which is totally legit. It's designed to be legit everywhere for building
>> on Linux...
>>
>> .if
>> !empty(CFLAGS:M*${SRCTOP}/sys:N*${SRCTOP}/sys/cddl/compat:N*${SRCTOP}/sys/crypto)
>>
>> would be a better test, imho.
>>
>
> Although, I could passively agressively work around it with
>
> CFLAGS+=-I${.CURDIR}/../../sys/sys/disk
>
> which also kinda defeats its purpose...
>
> Warner
>
>
>> Warner
>>
>> On Tue, Aug 21, 2018 at 8:11 AM, Alexander Richardson <
>> arichardson@freebsd.org> wrote:
>>
>>> In my testing 338129 fixed the issue. Seems like the problem is that
>>> bsd.crunchgen.mk iterates over all directories to do a make obj when
>>> it does the bootstrap-tools phase.
>>> On Tue, 21 Aug 2018 at 14:49, Warner Losh <imp@bsdimp.com> wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin <jhb@freebsd.org>
>>> wrote:
>>> >>
>>> >> On 8/20/18 9:00 PM, O. Hartmann wrote:
>>> >> > -----BEGIN PGP SIGNED MESSAGE-----
>>> >> > Hash: SHA512
>>> >> >
>>> >> > Am Mon, 20 Aug 2018 21:24:21 +0200
>>> >> > "O. Hartmann" <ohartmann@walstatt.org> schrieb:
>>> >> >
>>> >> >> -----BEGIN PGP SIGNED MESSAGE-----
>>> >> >> Hash: SHA512
>>> >> >>
>>> >> >> Building NanoBSD world on CURRENT r338113 fails due to:
>>> >> >>
>>> >> >> [...]
>>> >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde &&
>>> MK_TESTS=no
>>> >> >> UPDATE_DEPENDFILE=no  _RECURSING_CRUNCH=1
>>> >> >>
>>> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
>>> >> >> make  MK_AUTO_OBJ=no  DIRPRFX=rescue/rescue/gbde/ -DRESCUE
>>> CRUNCH_CFLAGS=-DRESCUE
>>> >> >> MK_AUTO_OBJ=no   obj make[5]:
>>> "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot"
>>> >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap
>>> tools.  Copy the header to
>>> >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead.  Error was
>>> caused by Makefile
>>> >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde]
>>> Error code 1
>>> >> >>
>>> >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
>>> >> >> [...]
>>> >> >>
>>> >> >>
>>> >> >> This problem occured during today's source updates since I was
>>> able to build the NanoBSD
>>> >> >> image I intend to build yesterday ~ r338060.
>>> >> >>
>>> >> >> What is going wrong?
>>> >> >
>>> >> > It seems the problem has been introduced after r338095, since
>>> r338095 builds ok, while
>>> >> > r338096 doesn't.
>>> >>
>>> >> 338096 added this check to catch a kind of error in our Makefiles.
>>> Alex (cc'd) can
>>> >> help with figuring out what the error is.
>>> >
>>> >
>>> > Except we're not building anything, we're making obj in rescue...  It
>>> looks like a false positive...
>>> >
>>> > Warner
>>>
>>
>>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BZ_v8qrFvN58cmwyHjTxsbUYRWtOUyw5Qmp=hu8r6mZGMvVoQ>