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

[Enji Cooper]

> 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,
-Enji