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

From: Yuri Pankov <yuripv_at_yuripv.net>
Date: Mon, 3 Dec 2018 21:14:28 +0300
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.


Received on Mon Dec 03 2018 - 17:14:39 UTC

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