Date: Thu, 18 Apr 2019 10:37:38 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Warner Losh <imp@bsdimp.com> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Kyle Evans <kevans@freebsd.org>, Cy Schubert <cy@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r346341 - head/tools/build Message-ID: <3E54A972-27CE-498F-B0B9-B65A6E87F213@cschubert.com> In-Reply-To: <CANCZdfqz4uueMc3qyXeyoODS%2BEyrf4GvNJVc7A4mftim%2BKdPig@mail.gmail.com> References: <201904181422.x3IEMrux005930@gndrsh.dnsmgr.net> <3095E422-7865-4EA5-BF13-6A48CB542AEE@cschubert.com> <CANCZdfrkON8J_6ZHt1UKa95G0=JLwZ8KoebspZzF0%2BeQ71BY4A@mail.gmail.com> <AA719490-5A6F-4218-90B8-FB7FA724C94E@cschubert.com> <CANCZdfqz4uueMc3qyXeyoODS%2BEyrf4GvNJVc7A4mftim%2BKdPig@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On April 18, 2019 9:59:50 AM PDT, Warner Losh <imp@bsdimp=2Ecom> wrote: >On Thu, Apr 18, 2019 at 10:26 AM Cy Schubert ><Cy=2ESchubert@cschubert=2Ecom> >wrote: > >> On April 18, 2019 8:11:49 AM PDT, Warner Losh <imp@bsdimp=2Ecom> wrote: >>> >>> >>> >>> On Thu, Apr 18, 2019 at 8:44 AM Cy Schubert ><Cy=2ESchubert@cschubert=2Ecom> >>> wrote: >>> >>>> On April 18, 2019 7:22:53 AM PDT, "Rodney W=2E Grimes" < >>>> freebsd@gndrsh=2Ednsmgr=2Enet> wrote: >>>> >> On Thu, Apr 18, 2019 at 8:46 AM Rodney W=2E Grimes >>>> >> <freebsd@gndrsh=2Ednsmgr=2Enet> wrote: >>>> >> > >>>> >> > > In message <201904180107=2Ex3I17QDc002945@gndrsh=2Ednsmgr=2Ene= t>, >>>> >"Rodney W=2E >>>> >> > > Grimes" >>>> >> > > writes: >>>> >> > > > > Author: cy >>>> >> > > > > Date: Thu Apr 18 01:02:00 2019 >>>> >> > > > > New Revision: 346341 >>>> >> > > > > URL: https://svnweb=2Efreebsd=2Eorg/changeset/base/346341 >>>> >> > > > > >>>> >> > > > > Log: >>>> >> > > > > As an interim measure until a more permanent solution >is >>>> >implemented >>>> >> > > > > workaround the following error: >>>> >> > > > > >>>> >> > > > > =20 >/usr/src/contrib/elftoolchain/strings/strings=2Ec:198:55: >>>> >error: use of >>>> >> > > > > undeclared identifier >>>> >> > > > > 'FA_OPEN' fa =3D fileargs_init(argc, argv, O_RDONLY, 0, >>>> >&rights, FA_OPEN); >>>> >> > > > > >>>> >> > > > > Reported by: O=2E Hartmann <ohartmann@walstatt=2Eorg> >>>> >> > > > > Reported by: Michael Butler ><imb@protected-networks=2Enet> >>>> >> > > > > Reported by: gjb@ & cy@ (implicit) >>>> >> > > > > Reviewed by: emaste@ >>>> >> > > > > Noted by: rgrimes@ >>>> >> > > > > >>>> >> > > > > Modified: >>>> >> > > > > head/tools/build/Makefile >>>> >> > > > > >>>> >> > > > > Modified: head/tools/build/Makefile >>>> >> > > > > >>>> >>>> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>>> >> > > > =3D=3D=3D >>>> >> > > > > --- head/tools/build/Makefile Thu Apr 18 00:38:54 >2019 >>>> > (r34634 >>>> >> > > > 0) >>>> >> > > > > +++ head/tools/build/Makefile Thu Apr 18 01:02:00 >2019 >>>> > (r34634 >>>> >> > > > 1) >>>> >> > > > > @@ -59,9 +59,7 @@ INCS+=3D capsicum_helpers=2Eh >>>> >> > > > > INCS+=3D libcasper=2Eh >>>> >> > > > > =2Eendif >>>> >> > > > > >>>> >> > > > > -=2Eif !exists(/usr/include/casper/cap_fileargs=2Eh) >>>> >> > > > > CASPERINC+=3D >>>> >${SRCTOP}/lib/libcasper/services/cap_fileargs/cap_filea >>>> >> > > > rgs=2Eh >>>> >> > > > > -=2Eendif >>>> >> > > > >>>> >> > > > As a further note, we should probably hunt for any thing >>>> >> > > > that is explicity looking at /usr/include/=2E=2E=2E in a >Makefile, >>>> >> > > > as that is minimally missing a ${DESTDIR} argument=2E >>>> >> > > > >>>> >> > > > The above may of actually worked if it had been written: >>>> >> > > > =2Eif !exists(${DESTDIR}/usr/include/casper/cap_fileargs=2Eh= ) >>>> >> > > > someone may wish to test that=2E >>>> >> > > > >>>> >> > > > Also a pathname rooted at / without ${DESTDIR} is almost >>>> >certainly a mistake=2E >>>> >> > > >>>> >> > > This is a better solution=2E I tested this in a tree with a >>>> >duplicated >>>> >> > > environment: Problem solved=2E Before this is committed it >should >>>> >be >>>> >> > > tested on one of the universe machines=2E >>>> >> > >>>> >> > From what Ed just said this would also be wrong, >>>> >> > as well as CASPERINC+=3D above being wrong, if this >>>> >> > is being built for the host we should not be using >>>> >> > any headers from ${SRCTOP} at all=2E >>>> >> > >>>> >> > if capfileargs=2Eh does not exist on the host that functionality >>>> >> > must not be compiled into the buildtool as the host does not >>>> >> > have this feature and attempting to use it from SRCTOP is >wrong=2E >>>> >> > >>>> >> >>>> >> Keep in mind that this is bootstrap; it's being built for the >host >>>> >> system, but it will link against a version of libcasper that's >been >>>> >> built in an earlier stage with the proper featureset=2E >>>> > >>>> >Ok, flip flop again, if infact this is linked against a >>>> >library that implements the stuff from cap_fileargs=2Eh then >>>> >infact the ${DESTDIR} addition so that the build peaks into >>>> >the cross build tree is correct, or what ever the equivelent >>>> >to DESTDIR is for that ? BUILDDIR? The point is it should >>>> >be picking this header up from the object tree, NOT from >>>> >the running system=2E >>>> >>>> Yes, this was my conclusion when working on kerberos and ntp=2E This >is >>>> also true of libraries, else one would need to installworld and >buildworld >>>> again to get a properly built library/binary=2E >>>> >>>> IIRC ngie@ fixed a number of these across the tree a couple of >years >>>> ago=2E >>> >>> >>> OK=2E There's a number of different issues going on=2E As the original >author >>> of libegacy (which is what we're seeing fail), let me address the >design >>> generically and comment on different things that have come up in >this >>> thread=2E >>> >>> Since this is going into the libegacy that we're using to build the >>> system, the check for file is bogus, for reasons I'll discuss below=2E > When >>> we add new includes to the system, it is appropriate to do it this >way=2E And >>> when this file was added to the system, the check was correct=2E >>> >>> First off, DESTDIR is absolutely not correct since this is to build >the >>> legacy library and legacy includes which augment the host's sources >on >>> legacay system, hence the name=2E It's never the correct thing to use= =2E >>> >>> The problem that we have here is not that the file is missing (which >is >>> why it was added the way it was a long time ago), but rather missing >>> functionality in a file that's been around for a long time=2E >>> >>> So, since it is that class of problem, the canonical way we've dealt >with >>> it in the past is to do something like create a file foo=2Eh that >looks >>> something like >>> >>> #include_next <foo=2Eh> >>> >>> #ifndev SOMETHING_NEW >>> #define SOMETHING_NEW 0 /* Or other values that are fail-safe on the >old >>> system */ >>> #endif >>> >>> and that's the change that needs to be made here=2E Sometimes, more >>> extensive things need to be done when the old library can't work at >all >>> with the new code=2E In those cases, the pattern is for foo=2Eh to >include >>> #define problem_fn my_problem_fn and then write a my_problem_fn that >wraps >>> problem_fn in a way that works on the old system=2E Kinda a poor man's >symbol >>> versioning, in a way (note: we can't use symbol version for this >since >>> we're building new binaries)=2E >>> >>> The "stop gap" gets things compiling, and maybe OK for the moment, >unless >>> the SOMETHING_NEW variable that's used (in this case FA_OPEN) causes >the >>> old library to do the wrong thing=2E I've not done the deep dive to >see if >>> this is the case or not=2E >>> >>> So, does that make sense? >>> >>> Warner >>> >> >> This solves one problem but what about the cases when a new krb5, >ntp, or >> amd is imported but fails to build because it is using the old >headers in >> /usr/include and linking against old libraries on the running system? >> >> These examples BTW have been fixed=2E My concern is there could be >other >> examples in contrib, yet to be discovered, that might also have the >same >> issues=2E >> > >That's the whole point if libegacy: to provide the glue that's needed >for >the bootstrap process=2E I'm surprised that ntp or amd are involved with >libegacy at all since they aren't bootstrap tools=2E Are you sure you >aren't >confusing two different problem domains? I know kerberos is, but it >kinda >needs to be=2E > >Warner Maybe I am conflating the two issues=2E I'll look again the next time I ge= t to a keyboard=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert <Cy=2ESchubert@cschubert=2Ecom> FreeBSD UNIX: <cy@FreeBSD=2Eorg> Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-svn-src-head@freebsd.org Thu Apr 18 18:02:05 2019 Return-Path: <owner-svn-src-head@freebsd.org> Delivered-To: svn-src-head@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 21748157823D; Thu, 18 Apr 2019 18:02:05 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3E537222E; Thu, 18 Apr 2019 18:02:04 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f52.google.com with SMTP id m188so1506825ioa.9; Thu, 18 Apr 2019 11:02:04 -0700 (PDT) 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=zj4LNXjz/2GuSOEUMX8Pe7F0GsmvqvcIkzsXk5yOrrQ=; b=m2T6sXN/O+7KKCEOt3zponhzubBjCqBB5Cih6fRmFCzPOENDoNQyd3Oq842NdsfkMq nskrJRiDp8Td/0U7VZpnyG0p8m2K4Oh2COnzYUchLays62bfNjKMxhWy5RbPWPzYac+o wrHMc9N2X5W6IiyHq59C+En6ru+08WHEyMn8AJaZH361uRqYutnUm696FmMMO1AO4q5U LS5szqde0jEnyEbWpUIQj9cYX9bGqkY2m2lVHE7QIj4T36zXRikalFdfrU/d5gqriVVU gRRPGh++/qdOLSZgYdxwK84zFgiEBsKrXWdOtd0pm7kLU7lWMUFiHnGr1RiMIWpOcstY qZHQ== X-Gm-Message-State: APjAAAVIDvCpsWO8s2wAkenmUSsOgLMrMmbKN/yPAJDfP8SNHRwp1xq7 YL3Xg1I3/ePLQ82QEcmyoVnj2Yo3yhEbHE2GQC9g5Q== X-Google-Smtp-Source: APXvYqxCIQ9atq0FLSFQUBoSo04LYTZdPdo8cG0uMhEjLt/L4l2VKgGZY5RZpcSsxvKw9V92ZR9WzQwt3rf33STQID8= X-Received: by 2002:a5d:8184:: with SMTP id u4mr10630269ion.239.1555610512079; Thu, 18 Apr 2019 11:01:52 -0700 (PDT) MIME-Version: 1.0 References: <201904180332.x3I3WJTt096491@slippy.cwsent.com> <201904181345.x3IDjgr4005764@gndrsh.dnsmgr.net> <CACNAnaEQWo6JE2p=8QpgCVe0kjMkt_p4Qe5qEi2wXFUyuC3kEw@mail.gmail.com> In-Reply-To: <CACNAnaEQWo6JE2p=8QpgCVe0kjMkt_p4Qe5qEi2wXFUyuC3kEw@mail.gmail.com> From: Ed Maste <emaste@freebsd.org> Date: Thu, 18 Apr 2019 14:01:39 -0400 Message-ID: <CAPyFy2D28h_jjPp4LgGqr+a-2qn+gSRUmLcnNozMyGCVuWsdcg@mail.gmail.com> Subject: Re: svn commit: r346341 - head/tools/build To: Kyle Evans <kevans@freebsd.org> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, Cy Schubert <Cy.Schubert@cschubert.com>, Cy Schubert <cy@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A3E537222E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/>; List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 18 Apr 2019 18:02:05 -0000 On Thu, 18 Apr 2019 at 10:03, Kyle Evans <kevans@freebsd.org> wrote: > > Keep in mind that this is bootstrap; it's being built for the host > system, but it will link against a version of libcasper that's been > built in an earlier stage with the proper featureset. Not exactly the case here: if building on a system with too-old Casper then strings just builds without Capsicum/Casper support. Macros / static inline stub implementations in the header takes care of this, it does not actually link against any libcasper.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E54A972-27CE-498F-B0B9-B65A6E87F213>