sys/modules/sdio broken in .svn_revision 348842 'opt_cam.h' not found

Tue Jun 18 02:53:28 UTC 2019

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.