From owner-freebsd-current@freebsd.org Mon Dec 3 17:53:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20BA2132E071 for ; Mon, 3 Dec 2018 17:53:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CB0A8CB2E for ; Mon, 3 Dec 2018 17:53:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x731.google.com with SMTP id w204so7884293qka.2 for ; Mon, 03 Dec 2018 09:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+v73Em4/ROxZbicQ8nMgCp5BQYzYEg5GzhSoRSrMXbk=; b=Sl8KHTPpPBlj3zuvUr+c+SWjH0MEqQFhGtIAoszsb8P98prZrFjXHcmiVQMxFGzqme nAOAq1u+9wfQL0mSP38dCUCN7hMW6rM1gpBD9bJrt+4wpSA90mQXQvcqmLAyyGq0VNIQ nK31vz/sB5sivz9YIECkzqqeYCP51zzfGyLU3oA5x/6kBMYNL/HKOUpuNZuBGMDnWWJs ckywTjXSgWkThp22Pny3J5in7u9TAXWC//dz1zvrMoMFno4+VOKFSxHW//3X5lIr/SNv W/e9TnUVpymyvYkNUBBthbkm7/1YXyr4VJPCaC804C9CR6tMmum6yvB0Q0mAeRRkhS7s xuGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+v73Em4/ROxZbicQ8nMgCp5BQYzYEg5GzhSoRSrMXbk=; b=Hy/tPc00/gdsyW5T+M50uGid05RwSg3SBKh77VPMsCcVrPYet0TXpQb4zVJMD6p26u nXzPwd5puEIQioQEEiel3mM4dtwBJx0inUo0EzFo5Rm/l6nKtKnMXT14iV3KpsuOBJuw s6HysdKr7CksVUtALDURj19FOr0ZIGcGdKxqrryDxMOqN7yoZKS/iVBFC1SZyRTiABdS Dbnc2sF9TVQTp3Zxq0/n9TlQEoWrhLgeJtlFEeix86R8ScFpL40YkczrScwNSR3L3IHY v1OwLj8zXtnx3z6HJQ3YBzM5aXWhyQkTN2FGsnPiA8eZEEyQ/85EHeoLX4Jmf8TtiopV ANXg== X-Gm-Message-State: AA+aEWaAOSDApFLL9Be1ZoB6IZMPS95t1XyB7k/hXpkn5ypaDmqOc+O0 fBTgZmojEUiuHdhwD+LJvLEiiFlAKJJPP1a2x6/74g== X-Google-Smtp-Source: AFSGD/WmjkjaNu8OgzYtEnZUaN+f2U+Jft+UnSKxPmzBC0XY4n8ovnELwxI/VG0DlTBZW4Yh1iwuM84iKktXnEngDd8= X-Received: by 2002:a37:6e86:: with SMTP id j128mr16256421qkc.46.1543859605704; Mon, 03 Dec 2018 09:53:25 -0800 (PST) MIME-Version: 1.0 References: <6e53765f-52bd-f503-c1a5-ae23e402afcb@yuripv.net> <20181203072226.mpvh7an5pupjbwkb@ivaldir.net> <51d0fa8c-b453-69e0-500e-32818d29826a@yuripv.net> In-Reply-To: From: Warner Losh Date: Mon, 3 Dec 2018 10:53:14 -0700 Message-ID: Subject: Re: WITH_CTF breaks CD loader: "File too big" To: Yuri Pankov Cc: Baptiste Daroussin , FreeBSD Current X-Rspamd-Queue-Id: 5CB0A8CB2E X-Spamd-Result: default: False [-5.21 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.22)[ip: (-8.04), ipnet: 2607:f8b0::/32(-1.66), asn: 15169(-1.30), country: US(-0.09)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 17:53:27 -0000 On Mon, Dec 3, 2018 at 9:56 AM Yuri Pankov wrote: > Yuri Pankov wrote: > > Warner Losh wrote: > >> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote: > >> > >>> > >>> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin > >>> 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