From owner-svn-src-all@freebsd.org Tue Sep 3 14:07:58 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B3571DD45C; Tue, 3 Sep 2019 14:07:05 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N8090tbkz4QDN; Tue, 3 Sep 2019 14:07:05 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id D48DA1B076; Tue, 3 Sep 2019 14:06:27 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id B25A798E2; Thu, 18 Apr 2019 17:00:08 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67B426EF26; Thu, 18 Apr 2019 17:00:07 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 3B0E6987D; Thu, 18 Apr 2019 17:00:07 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id AD8E99875 for ; Thu, 18 Apr 2019 17:00:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 E2DE36EF12 for ; Thu, 18 Apr 2019 17:00:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id x18so1532049qkf.13 for ; Thu, 18 Apr 2019 10:00:02 -0700 (PDT) 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=DQV4bb7NwbFZ1QubfQTqh0TYWQr2iSr4H9I8BVBIfKE=; b=1NHIVnE1wUKk1o1gHdZiRjJZ3u30N0ZdIJPsSxsvMJ7lyuevJ0xeGYcBm8DdO1JVqU TugaOidE7Zgv4tQbp4jPsTJWm/QsXg0b+IaO6M2dg4+33gE9CLdGGJgwW08QOs5cky3l qH2Y/fto1jVkgPvmSFn1X0wER3LSz79e1FmnpDD/zwUZHvYo4YJP4xY9cc+iK0BIVhb6 CpkgU1KzlQhZXWW/g44tIJ7/U93NgX8F/UBw/n9usQtPfhqkkJ6MbdzJQdiepTpwvAnZ 9arXp6uYm7iC56vfS2ftMRfO6xPM5eOska/x06CBO4e6roHRCHKHRuDMILEdFBE/cXKQ o/UQ== 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=DQV4bb7NwbFZ1QubfQTqh0TYWQr2iSr4H9I8BVBIfKE=; b=Ntoi6Y7TP3cYoPOVfttgqUH2ZD6+pyMo5n9r6U/zR8WqpnihrxAjGAl+ypnWx0nj+J jQZjAMGkhiiqL9lnmvCInxfAiZ5nhfHcr0k6Po1CzJZT42Yg5FHiZHOq5CdW63HcnnlS H68drj0bnsJPP8g+tjzaLjStYmxIoMeKQN4Gu4HPFhjUKZmTtpnogn+LcLHs7CbfjuAA ng47mQSqZTGhA41OaSKxuxo3K5E42aPKJxNjIR/c0L8xHk5YKWjap2622RzPAJS6Rg20 EuvsL3RGutj81FjVmFrAOL7pVCrnfhAXLMRrZl4IhwRbg+tvbTCAT6vP+4bEfFO4diDR k+Bw== X-Gm-Message-State: APjAAAUaZRhCnK4EziKkIGF89Ds7A5KIqFul4BYhFd2h3B2UHQMwOB9z k1+7EPvm2bqpZQekLuc7kp6P+yyenbOc2mzomH3t1A== X-Google-Smtp-Source: APXvYqzf2sTTeWKfNbzGtsoTBgp9s2Inshh3qIKEFmIrjVPxo/E74BfIrvu36h7IllKbzvx0P7WWk6EcmXMLW/k9owY= X-Received: by 2002:a05:620a:11a6:: with SMTP id c6mr10663183qkk.46.1555606802302; Thu, 18 Apr 2019 10:00:02 -0700 (PDT) MIME-Version: 1.0 References: <201904181422.x3IEMrux005930@gndrsh.dnsmgr.net> <3095E422-7865-4EA5-BF13-6A48CB542AEE@cschubert.com> In-Reply-To: From: Warner Losh Message-ID: Subject: Re: svn commit: r346341 - head/tools/build To: Cy Schubert Cc: "Rodney W. Grimes" , "Rodney W. Grimes" , Kyle Evans , Cy Schubert , src-committers , svn-src-all , svn-src-head Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 67B426EF26 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 03 Sep 2019 14:07:58 -0000 X-Original-Date: Thu, 18 Apr 2019 10:59:50 -0600 X-List-Received-Date: Tue, 03 Sep 2019 14:07:58 -0000 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. Grimes" < >>> freebsd@gndrsh.dnsmgr.net> wrote: >>> >> On Thu, Apr 18, 2019 at 8:46 AM Rodney W. Grimes >>> >> wrote: >>> >> > >>> >> > > In message <201904180107.x3I17QDc002945@gndrsh.dnsmgr.net>, >>> >"Rodney W. >>> >> > > Grimes" >>> >> > > writes: >>> >> > > > > Author: cy >>> >> > > > > Date: Thu Apr 18 01:02:00 2019 >>> >> > > > > New Revision: 346341 >>> >> > > > > URL: https://svnweb.freebsd.org/changeset/base/346341 >>> >> > > > > >>> >> > > > > Log: >>> >> > > > > As an interim measure until a more permanent solution is >>> >implemented >>> >> > > > > workaround the following error: >>> >> > > > > >>> >> > > > > /usr/src/contrib/elftoolchain/strings/strings.c:198:55: >>> >error: use of >>> >> > > > > undeclared identifier >>> >> > > > > 'FA_OPEN' fa = fileargs_init(argc, argv, O_RDONLY, 0, >>> >&rights, FA_OPEN); >>> >> > > > > >>> >> > > > > Reported by: O. 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 >>> >> > > > > >>> >>> >=========================================================================== >>> >> > > > === >>> >> > > > > --- 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+= capsicum_helpers.h >>> >> > > > > INCS+= libcasper.h >>> >> > > > > .endif >>> >> > > > > >>> >> > > > > -.if !exists(/usr/include/casper/cap_fileargs.h) >>> >> > > > > CASPERINC+= >>> >${SRCTOP}/lib/libcasper/services/cap_fileargs/cap_filea >>> >> > > > rgs.h >>> >> > > > > -.endif >>> >> > > > >>> >> > > > As a further note, we should probably hunt for any thing >>> >> > > > that is explicity looking at /usr/include/... in a Makefile, >>> >> > > > as that is minimally missing a ${DESTDIR} argument. >>> >> > > > >>> >> > > > The above may of actually worked if it had been written: >>> >> > > > .if !exists(${DESTDIR}/usr/include/casper/cap_fileargs.h) >>> >> > > > someone may wish to test that. >>> >> > > > >>> >> > > > Also a pathname rooted at / without ${DESTDIR} is almost >>> >certainly a mistake. >>> >> > > >>> >> > > This is a better solution. I tested this in a tree with a >>> >duplicated >>> >> > > environment: Problem solved. Before this is committed it should >>> >be >>> >> > > tested on one of the universe machines. >>> >> > >>> >> > From what Ed just said this would also be wrong, >>> >> > as well as CASPERINC+= above being wrong, if this >>> >> > is being built for the host we should not be using >>> >> > any headers from ${SRCTOP} at all. >>> >> > >>> >> > if capfileargs.h 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. >>> >> > >>> >> >>> >> 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. >>> > >>> >Ok, flip flop again, if infact this is linked against a >>> >library that implements the stuff from cap_fileargs.h 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. >>> >>> Yes, this was my conclusion when working on kerberos and ntp. This is >>> also true of libraries, else one would need to installworld and buildworld >>> again to get a properly built library/binary. >>> >>> IIRC ngie@ fixed a number of these across the tree a couple of years >>> ago. >> >> >> OK. There's a number of different issues going on. 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. >> >> 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. When >> we add new includes to the system, it is appropriate to do it this way. And >> when this file was added to the system, the check was correct. >> >> 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. It's never the correct thing to use. >> >> 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. >> >> 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.h 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. Sometimes, more >> extensive things need to be done when the old library can't work at all >> with the new code. In those cases, the pattern is for foo.h 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. 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). >> >> 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. I've not done the deep dive to see if >> this is the case or not. >> >> 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. My concern is there could be other > examples in contrib, yet to be discovered, that might also have the same > issues. > That's the whole point if libegacy: to provide the glue that's needed for the bootstrap process. I'm surprised that ntp or amd are involved with libegacy at all since they aren't bootstrap tools. Are you sure you aren't confusing two different problem domains? I know kerberos is, but it kinda needs to be. Warner