Re: WITH_CTF breaks CD loader: "File too big"

From: Warner Losh <imp_at_bsdimp.com>
Date: Mon, 3 Dec 2018 10:53:14 -0700
On Mon, Dec 3, 2018 at 9:56 AM Yuri Pankov <yuripv_at_yuripv.net> wrote:

> Yuri Pankov wrote:
> > Warner Losh wrote:
> >> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh <imp_at_bsdimp.com> wrote:
> >>
> >>>
> >>> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin <bapt_at_freebsd.org>
> >>> wrote:
> >>>
> >>>> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Building disc1.iso using `make release` and having WITH_CTF set in
> >>>>> src.conf leads to "File too big" displayed when booting the image.
> >>>>>
> >>>>> Would it make sense to build loader and related parts without CTF
> >>>>> unconditionally as it doesn't look useful there?
> >>>>>
> >>>>
> >>>> Fully agree with you
> >>>>
> >>>
> >>> What a great Idea. We already turn it off in defs.mk:
> >
> > Sorry about that, I incorrectly assumed it wasn't done yet as there was
> > a difference for me.
> >
> >>> MK_CTF=         no
> >>>
> >>> which should be global to every single Makefile under stand. I'm not
> sure
> >>> why that's turning it back on.
> >>>
> >>
> >> % cat /etc/src.conf
> >> WITH_CTF=yes
> >> FRED=present
> >> % cd stand/cdboot
> >> % make -V MK_CTF
> >> no
> >> % make -V FRED
> >> present
> >> %
> >>
> >> So this sure sounds like a false positive to me. Do you have logs
> showing
> >> cdboot building with MK_CTF=yes?
> >
> > Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of
> > ctfconvert calls in the latter case.  Attached is the diff of binary
> > sizes in obj/ for stand/i386; could one of those be the problem I'm
> seeing?
>
> If ctfconvert calls are indeed the source of problem, then something
> seems to be wrong here (I didn't mention the "cdboot" binary exactly,
> rather the binary it's trying to load):
>
> yuripv:~/ws/ctf/stand/i386/loader$ make -V MK_CTF -V CTFCONVERT_CMD
> no
>
> yuripv:~/ws/ctf/stand/i386/loader$ make -DWITH_CTF -V MK_CTF -V
> CTFCONVERT_CMD
> no
> ctfconvert -L VERSION ${.TARGET}
>

Ding! We have a winner:  order of operations not quite right. We included
src.opts.mk which includes bsd.own.mk which defines CTFCONVERT_CMD and then
we change the MK_CTF value which has no effect. Unlike the lazy evaluation
in makefile rules, where the last one wins, when we're parsing stuff for
.if, it's the current value that's used. The solution is to include
src.opts.mk later after we set the MK_foo overrides.

r341433 should fix that.

Warner
Received on Mon Dec 03 2018 - 16:53:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:19 UTC