Date: Tue, 4 Dec 2018 00:00:23 +0300 From: Yuri Pankov <yuripv@yuripv.net> To: Warner Losh <imp@bsdimp.com> Cc: Baptiste Daroussin <bapt@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: WITH_CTF breaks CD loader: "File too big" Message-ID: <c66f1634-771a-b7e7-3137-ccc35654dfa4@yuripv.net> In-Reply-To: <CANCZdfrFbwmaLAKcMc8Zq2iypGAM0jxxGX%2Bs2%2Bh%2B3cUCGhEGOw@mail.gmail.com> References: <6e53765f-52bd-f503-c1a5-ae23e402afcb@yuripv.net> <20181203072226.mpvh7an5pupjbwkb@ivaldir.net> <CANCZdfojEB2ge7=L51ZhT8P4igY9UiCx=aFUcZFCZOUdDdQFjg@mail.gmail.com> <CANCZdfpN6SSRBMFt3SnxDRKz=cNUmtYmJimJAGHtB%2BqZZuNhYw@mail.gmail.com> <51d0fa8c-b453-69e0-500e-32818d29826a@yuripv.net> <cb28f786-c6ad-930b-6f1a-03e9ab636a79@yuripv.net> <CANCZdfpup0VuT0p9ZYyv7rx_OzS-DOaT=eyoEq2mKecjBhj_QQ@mail.gmail.com> <a7ec7948-1442-ef92-d38e-292171018239@yuripv.net> <CANCZdfrFbwmaLAKcMc8Zq2iypGAM0jxxGX%2Bs2%2Bh%2B3cUCGhEGOw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4747jgS1C3Od1olATYjOrz6uRTnW2lODU
Content-Type: multipart/mixed; boundary="aLMB4jmQHyhth5JJJldBEwBIQCaGv74c7";
protected-headers="v1"
From: Yuri Pankov <yuripv@yuripv.net>
To: Warner Losh <imp@bsdimp.com>
Cc: Baptiste Daroussin <bapt@freebsd.org>,
FreeBSD Current <freebsd-current@freebsd.org>
Message-ID: <c66f1634-771a-b7e7-3137-ccc35654dfa4@yuripv.net>
Subject: Re: WITH_CTF breaks CD loader: "File too big"
References: <6e53765f-52bd-f503-c1a5-ae23e402afcb@yuripv.net>
<20181203072226.mpvh7an5pupjbwkb@ivaldir.net>
<CANCZdfojEB2ge7=L51ZhT8P4igY9UiCx=aFUcZFCZOUdDdQFjg@mail.gmail.com>
<CANCZdfpN6SSRBMFt3SnxDRKz=cNUmtYmJimJAGHtB+qZZuNhYw@mail.gmail.com>
<51d0fa8c-b453-69e0-500e-32818d29826a@yuripv.net>
<cb28f786-c6ad-930b-6f1a-03e9ab636a79@yuripv.net>
<CANCZdfpup0VuT0p9ZYyv7rx_OzS-DOaT=eyoEq2mKecjBhj_QQ@mail.gmail.com>
<a7ec7948-1442-ef92-d38e-292171018239@yuripv.net>
<CANCZdfrFbwmaLAKcMc8Zq2iypGAM0jxxGX+s2+h+3cUCGhEGOw@mail.gmail.com>
In-Reply-To: <CANCZdfrFbwmaLAKcMc8Zq2iypGAM0jxxGX+s2+h+3cUCGhEGOw@mail.gmail.com>
--aLMB4jmQHyhth5JJJldBEwBIQCaGv74c7
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Warner Losh wrote:
> On Mon, Dec 3, 2018 at 11:14 AM Yuri Pankov <yuripv@yuripv.net> wrote:
>=20
>> Warner Losh wrote:
>>> On Mon, Dec 3, 2018 at 9:56 AM Yuri Pankov <yuripv@yuripv.net> wrote:=
>>>
>>>> Yuri Pankov wrote:
>>>>> Warner Losh wrote:
>>>>>> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh <imp@bsdimp.com> wrote:=
>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin <bapt@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 ima=
ge.
>>>>>>>>>
>>>>>>>>> Would it make sense to build loader and related parts without C=
TF
>>>>>>>>> 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=3D 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=3Dyes
>>>>>> FRED=3Dpresent
>>>>>> % 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=3Dyes?
>>>>>
>>>>> 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 binar=
y
>>>>> 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 incl=
uded
>>> src.opts.mk which includes bsd.own.mk which defines CTFCONVERT_CMD an=
d
>> 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.
>>
>=20
> Please give it a spin and let me know if we're golden. I'll MFC it then=
> since this should be in 12.1.
Done. Everything looks good now - having clean /usr/obj/; world/kernel
built with WITH_CTF=3D in /etc/src.conf; successfully booted the disc1.is=
o
built using `make cdrom`.
--aLMB4jmQHyhth5JJJldBEwBIQCaGv74c7--
--4747jgS1C3Od1olATYjOrz6uRTnW2lODU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE+Gq3PsPeLT4tL/9wk4vgf7Eq4WwFAlwFmWgACgkQk4vgf7Eq
4WwfmQf/U4MBznFtOHZmFF4sfChMcQhdamntuYm2Knu6OUYcG9QknuVe0QEC9131
8GVqaBRj7d4tW+BEBTeKLk7hQhQdwYkA+qfGYrYmcu0DxvemR9sa/CyS6fj1srJj
5hy5sjuk0iTzDHSUyBUShYI3XWOoAGKkQdKOfM4/nb8GcSmAoR3jkUxWNv1jus41
7zon4tb31gnOyBpOe3LupdYuP9Mly/sa3h/wMBHhmrL+vInH9e2tzstZvxJv7SS0
8XTR4a9VI5DfE54QEgTk+12W4MIO4VjyzMhLhlXwgzFOVSLZfjppvLimIYA7mPPB
cuQ2aDSir8j8QIK64ocTo46ekrQEYw==
=14b+
-----END PGP SIGNATURE-----
--4747jgS1C3Od1olATYjOrz6uRTnW2lODU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c66f1634-771a-b7e7-3137-ccc35654dfa4>