Date: Thu, 18 Apr 2019 07:43:43 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: rgrimes@freebsd.org, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Kyle Evans <kevans@freebsd.org> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, Cy Schubert <cy@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r346341 - head/tools/build Message-ID: <3095E422-7865-4EA5-BF13-6A48CB542AEE@cschubert.com> In-Reply-To: <201904181422.x3IEMrux005930@gndrsh.dnsmgr.net> References: <201904181422.x3IEMrux005930@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On April 18, 2019 7:22:53 AM PDT, "Rodney W=2E Grimes" <freebsd@gndrsh=2Edn= smgr=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=2Enet>, >"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: >> > > > > >> > > > > /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 =20 > (r34634 >> > > > 0) >> > > > > +++ head/tools/build/Makefile Thu Apr 18 01:02:00 2019 =20 > (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 =20 >${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 >> > >>=20 >> 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 al= so true of libraries, else one would need to installworld and buildworld a= gain to get a properly built library/binary=2E=20 IIRC ngie@ fixed a number of these across the tree a couple of years ago= =2E=20 --=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3095E422-7865-4EA5-BF13-6A48CB542AEE>