Warner Losh wrote: > 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. Thank you.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:19 UTC