From owner-svn-src-head@freebsd.org Thu Apr 18 17:37:46 2019 Return-Path: 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 432C215775FE; Thu, 18 Apr 2019 17:37:46 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 04C257067C; Thu, 18 Apr 2019 17:37:44 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id HAyhhxYtqsAGkHAyjhLtfn; Thu, 18 Apr 2019 11:37:42 -0600 X-Authority-Analysis: v=2.3 cv=WeVylHpX c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=oexKYjalfGEA:10 a=7Qk2ozbKAAAA:8 a=YxBL1-UpAAAA:8 a=iKhvJSA4AAAA:8 a=6I5d2MoRAAAA:8 a=iaTFZB6CAAAA:8 a=zxA2vyXaAAAA:8 a=PEp_QB5gzuGBnP-JFm0A:9 a=7FaDiMKna2wrQ8zq:21 a=zHhFJdDF3MAfcgv_:21 a=QEXdDO2ut3YA:10 a=K0OccMdgBH2YJbIUUJkA:9 a=E0xnkuw_hmWRA0Fy:21 a=L5zBaabDEDj39vuA:21 a=Vjm11AqRlWPGOZTs:21 a=_W_S_7VecoQA:10 a=1lyxoWkJIXJV6VJUPhuM:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=odh9cflL3HIXMm4fY7Wr:22 a=IjZwj45LgO3ly-622nXo:22 a=QWXrQ9iV8q7LKaLQ9lfw:22 a=nK2txNHJmq7TfjpuLlwI:22 Received: from [192.168.0.103] (S0106002401cb186f.gv.shawcable.net [70.67.125.17]) by spqr.komquats.com (Postfix) with ESMTPSA id 28A8813AF; Thu, 18 Apr 2019 10:37:39 -0700 (PDT) Date: Thu, 18 Apr 2019 10:37:38 -0700 User-Agent: K-9 Mail for Android In-Reply-To: References: <201904181422.x3IEMrux005930@gndrsh.dnsmgr.net> <3095E422-7865-4EA5-BF13-6A48CB542AEE@cschubert.com> MIME-Version: 1.0 Subject: Re: svn commit: r346341 - head/tools/build To: Warner Losh CC: "Rodney W. Grimes" , "Rodney W. Grimes" , Kyle Evans , Cy Schubert , src-committers , svn-src-all , svn-src-head From: Cy Schubert Message-ID: <3E54A972-27CE-498F-B0B9-B65A6E87F213@cschubert.com> X-CMAE-Envelope: MS4wfEmillLAy8HivkgIF8cTyGi5emn60y0OAGShBwcF0QIiRmAcw+7+EjCZto7n2UWEO26TMVewDM1kbS5atDBvnpEfPRUI3sQgYNGrMVDlkIHlFqFR6gzT J/V1mOO2nI1QyFDbgg7JW3KdBZRONtMRoB74gh5WD8JDefd5VTpMDCKXhusqSRGxCVAfSAOuweZUlEVZKI7yafVTQntYmfpe5HqtJeGEFG1mRiIrxcv8WMns q5FO3bV2zwd5vmLV1YqpNFHWk3AXejTfnU2ZWPGuceaq5sUeqoLSxHi5BycxJYIxbQaGIUIGR+M+5ST5XZnKO/XffIamWQS5AVY+91RgUN1zcsngHZz9+3gA SYCRp95rR5KtQ7neMu+LzDxf9E4FpbA3wRiBcdls+GpUpBCgJcHmlrtBBqKfK7szHpfKWD+J X-Rspamd-Queue-Id: 04C257067C X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.992,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 17:37:46 -0000 On April 18, 2019 9:59:50 AM PDT, Warner Losh wrote: >On Thu, Apr 18, 2019 at 10:26 AM Cy Schubert > >wrote: > >> On April 18, 2019 8:11:49 AM PDT, Warner Losh wrote: >>> >>> >>> >>> On Thu, Apr 18, 2019 at 8:44 AM Cy Schubert > >>> 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 >>>> >> 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 >>>> >> > > > > Reported by: Michael Butler > >>>> >> > > > > 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 >>> >>> #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 FreeBSD UNIX: 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: 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> In-Reply-To: From: Ed Maste Date: Thu, 18 Apr 2019 14:01:39 -0400 Message-ID: Subject: Re: svn commit: r346341 - head/tools/build To: Kyle Evans Cc: "Rodney W. Grimes" , Cy Schubert , Cy Schubert , src-committers , svn-src-all , svn-src-head 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 18:02:05 -0000 On Thu, 18 Apr 2019 at 10:03, Kyle Evans 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.