> On Jun 17, 2019, at 18:26, Cy Schubert <Cy.Schubert_at_cschubert.com> wrote: > > Now that I'm back home, to reply inline re the yacc.h issue. > > In message <201906180021.x5I0L2RK057837_at_fire.js.berklix.net>, "Julian > H. Stacey > " writes: >> "Julian H. Stacey" wrote: >>> "Bjoern A. Zeeb" wrote: >>>>> On 17 Jun 2019, at 10:37, Mark Linimon wrote: >>>>> >>>>>> 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. >>>>> >>>>> This is extremely unlikely to be r348842. I would investigate r349025 >>>>> instead. (Committer Cc:ed.) >>>> >>>> Almost, more likely me. I just had a look. I am not exactly sure how >>>> to reproduce this? >>>> >>>> /bz >>> >>> If I can help let me know. >>> My buildworld broke with 13.0-CURRENT >>> /usr/src .ctm_status src-cur 14077 .svn_revision 348842 >>> I'm now running make install, >>> & can then compare my root include & libs with with a set installed >>> using DESTDIR= >> >> I compiled, installed, compared. >> 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=YES so manually purged >> , >> 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. >> >> 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 options. 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. >> >> make buildworld blew on newer current, with a different bug: >> >> 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 >> -MF.depend.lex.o -MTlex.o -std=gnu99 -Qunused-arguments -I/usr/obj/usr/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 >> >> Stop. >> make[3]: stopped in /usr/src/usr.bin/mkesdb_static > > 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$ > >> >> 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. > > Calm down. This looks like a corrupted obj directory, corrupted src > tree, or user error to me and it doesn't matter right now anyway. rm > -rf /usr/obj or wherever you keep it and start afresh. I’d have to look further, and we’d need to know more details about your build environment (ccache? bmake with meta mode? -DNO_CLEAN? Objects built on tmpfs? Compiler/toolchain/world version?), but I’m definitely biased towards the approach that Cy mentions if the issue is deterministically failing with the same issue by just repeating the build process. I side with Cy because there’s also a nonzero chance that one of the intermediary files generated by byacc got corrupted and got picked up in the next run. However that directory’s enough of a special snowflake that I don’t feel comfortable betting all my money on that possibility. Cheers, -EnjiReceived on Tue Jun 18 2019 - 00:10:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC