In message <B3025522-D20F-4004-818B-F781A87A0A31_at_gmail.com>, Enji Cooper writes : > > > > 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 purg > ed > >> , > >> 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 optio > ns. 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_s > tat > >> ic/../mkesdb -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv -g -M > D > >> -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 b > uild environment (ccache? bmake with meta mode? -DNO_CLEAN? Objects built on > tmpfs? Compiler/toolchain/world version?), but I’m definitely biased toward > s the approach that Cy mentions if the issue is deterministically failing wit > h the same issue by just repeating the build process. If a person knows what they're doing they can rm -r the subdirectory causing the problem. Even deleting the individual file that is the cause. Having said that, there libraries that are depended on that should be deleted. Don't forget that sysroot might be where the failure might be, so people end up looking for the unloved file in the wrong place. If a person doesn't know what they're doing they're best off removing the entire object tree and starting over. BTW, IMO a person saves a bit of time by rm -r /usr/obj/* and building with -DNO_CLEAN. It doesn't need to go through make clean phase first. I mv /usr/obj/opt /usr/obj/foobar; rm -rf foobar & make -DNO_CLEAN buildworld when I start afresh. > > I side with Cy because there’s also a nonzero chance that one of the interm > ediary files generated by byacc got corrupted and got picked up in the next r > un. However that directory’s enough of a special snowflake that I don’t f > eel comfortable betting all my money on that possibility. Our build system has many moving parts and is not for the faint of heart. And, very easy to get something wrong. Even make tinderbox doesn't catch absolutely everything. -- Cheers, Cy Schubert <Cy.Schubert_at_cschubert.com> FreeBSD UNIX: <cy_at_FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.Received on Tue Jun 18 2019 - 00:53:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC