Date: Mon, 17 Jun 2019 19:10:40 -0700 From: Enji Cooper <yaneurabeya@gmail.com> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: "Julian H. Stacey" <jhs@berklix.com>, "Bjoern A. Zeeb" <bz@freebsd.org>, current@freebsd.org Subject: Re: sys/modules/sdio broken in .svn_revision 348842 'opt_cam.h' not found Message-ID: <B3025522-D20F-4004-818B-F781A87A0A31@gmail.com> In-Reply-To: <201906180126.x5I1QPsD004821@slippy.cwsent.com> References: <201906180126.x5I1QPsD004821@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jun 17, 2019, at 18:26, Cy Schubert <Cy.Schubert@cschubert.com> wrote: >=20 > Now that I'm back home, to reply inline re the yacc.h issue. >=20 > In message <201906180021.x5I0L2RK057837@fire.js.berklix.net>, "Julian=20 > H. Stacey > " writes: >> "Julian H. Stacey" wrote: >>> "Bjoern A. Zeeb" wrote: >>>>> On 17 Jun 2019, at 10:37, Mark Linimon wrote: >>>>>=20 >>>>>> On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey wrote: >>>>>> svn_revision 348842 >>>>> [ ...] >>>>>> /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal error: >>>>>> 'opt_cam.h' file not found >>>>>> #include "opt_cam.h" >>>>>> ^~~~~~~~~~~ >>>>>> 1 error generated. >>>>>=20 >>>>> This is extremely unlikely to be r348842. I would investigate r349025= >>>>> instead. (Committer Cc:ed.) >>>>=20 >>>> Almost, more likely me. I just had a look. I am not exactly sure how=20= >>>> to reproduce this? >>>>=20 >>>> /bz >>>=20 >>> If I can help let me know. >>> My buildworld broke with 13.0-CURRENT=20 >>> /usr/src .ctm_status src-cur 14077 .svn_revision 348842 >>> I'm now running make install,=20 >>> & can then compare my root include & libs with with a set installed=20 >>> using DESTDIR=3D >>=20 >> I compiled, installed, compared. =20 >> BTW cd /usr/src; make delete - only cleans libs & bins but does not >> clean other junk listed in ObsoleteFiles.inc not even with >> -DBATCH_DELETE_OLD_FILES or -DBATCH_DELETE_OLD_FILES=3DYES so manually p= urged >> , >> I believe I have a clean system built from .ctm_status src-cur 14077 >> .svn_revision 348842 but /usr/src/sys/modules/sdio still fails, >> so there was a commit of unbuildable code. >>=20 >> cd /usr/src ; find . -name opt_cam.h # tools/tools/vhba/opt_cam.h >> cd /usr/include ; find . -name opt_cam.h # nothing opt_*.h are headers which tune the kernel build based on user-specified opti= ons. They should never be shipped as part of the base OS. >>> I have a 2nd slower current box also building to 14077, I will then >>> take that on up to latest .ctm_status src-cur 14087 .svn_revision >>> 349129 to see if problem clears. >>=20 >> make buildworld blew on newer current, with a different bug: >>=20 >> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static -I/usr/src/usr.bin/mkesdb_= stat >> ic/../mkesdb -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv -g -= MD =20 >> -MF.depend.lex.o -MTlex.o -std=3Dgnu99 -Qunused-arguments -I/usr/obj/u= sr/src >> /amd64.amd64/tmp/legacy/usr/include -c lex.c -o lex.o >> /usr/src/usr.bin/mkesdb/lex.l:46:10: fatal error: 'yacc.h' file not found= >> #include "yacc.h" >> ^~~~~~~~ >> 1 error generated. >> *** Error code 1 >>=20 >> Stop. >> make[3]: stopped in /usr/src/usr.bin/mkesdb_static >=20 > slippy$ ls /export/obj/opt/src/svn-current/amd64.amd64/usr.bin/mkesdb > lex.c mkesdb.1.gz mkesdb.full.meta yacc.o > lex.c.meta mkesdb.1.gz.meta mkesdb.meta yacc.o.meta > lex.o mkesdb.debug yacc.c > lex.o.meta mkesdb.debug.meta yacc.c.meta > mkesdb mkesdb.full yacc.h <---- here it is > slippy$=20 >=20 >>=20 >> A double waste of CPU & human time & power in a hot office. >> Commit bits used to be suspended for un-buildable code. I'll boot stable.= >=20 > Calm down. This looks like a corrupted obj directory, corrupted src=20 > tree, or user error to me and it doesn't matter right now anyway. rm=20 > -rf /usr/obj or wherever you keep it and start afresh. I=E2=80=99d have to look further, and we=E2=80=99d need to know more details= about your build environment (ccache? bmake with meta mode? -DNO_CLEAN? Obj= ects built on tmpfs? Compiler/toolchain/world version?), but I=E2=80=99m def= initely biased towards the approach that Cy mentions if the issue is determi= nistically failing with the same issue by just repeating the build process. I side with Cy because there=E2=80=99s also a nonzero chance that one of the= intermediary files generated by byacc got corrupted and got picked up in th= e next run. However that directory=E2=80=99s enough of a special snowflake t= hat I don=E2=80=99t feel comfortable betting all my money on that possibilit= y. Cheers, -Enji=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B3025522-D20F-4004-818B-F781A87A0A31>