From owner-freebsd-current@freebsd.org Tue Jun 18 02:53:28 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62B2315CC678 for ; Tue, 18 Jun 2019 02:53:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C75618E6C1 for ; Tue, 18 Jun 2019 02:53:27 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8401915CC677; Tue, 18 Jun 2019 02:53:27 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 443EF15CC676 for ; Tue, 18 Jun 2019 02:53:27 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B75378E6BF; Tue, 18 Jun 2019 02:53:25 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id d4FNheFdOGusjd4FOhHk4z; Mon, 17 Jun 2019 20:53:23 -0600 X-Authority-Analysis: v=2.3 cv=fOdHIqSe c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=8nJEP1OIZ-IA:10 a=dq6fvYVFJ5YA:10 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=Ikt0M2cxAAAA:8 a=6I5d2MoRAAAA:8 a=bZ6pEpDQa2lGXZwkr14A:9 a=wPNLvfGTeEIA:10 a=trcp-C1S3fIA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=iYm7J9qDpiSF5xNCBZUT:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 9FDC690A; Mon, 17 Jun 2019 19:53:19 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x5I2rJPp005430; Mon, 17 Jun 2019 19:53:19 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x5I2rIBE005427; Mon, 17 Jun 2019 19:53:19 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201906180253.x5I2rIBE005427@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Enji Cooper cc: Cy Schubert , "Julian H. Stacey" , "Bjoern A. Zeeb" , current@freebsd.org Subject: Re: sys/modules/sdio broken in .svn_revision 348842 'opt_cam.h' not found In-Reply-To: Message from Enji Cooper of "Mon, 17 Jun 2019 19:10:40 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 17 Jun 2019 19:53:18 -0700 X-CMAE-Envelope: MS4wfKrVBerUWWgLbsJZa8Bl8T5R2CqTFZRyDpYQPLwUKa0Q4ouS9p/yyPN4Rm5CHv1yzIbykOfjG37/nUYvjcLug+sOy/+iEAZn0lwQOFsjltf7TBnt8bmW +zlK3FI1HUXUrR5VdlPBbbSIf+BgTj0E4EA1Ugp/nEH12nclmOjkwuEtItQuji4pX/SIFrQSyeagAWp81VtqkJzkIrcZnhmjOEs5s0R6wCyu8tMMBDbiuOY3 fUpczxHWCS8fkQKCMHBG6/q7TyK+yvUZXpMonuYEwiY= X-Rspamd-Queue-Id: B75378E6BF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.93)[-0.929,0]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; RCVD_IN_DNSWL_LOW(-0.10)[139.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.35)[ip: (-5.90), ipnet: 64.59.128.0/20(-3.26), asn: 6327(-2.52), country: CA(-0.09)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 02:53:28 -0000 In message , Enji Cooper writes : > > > > On Jun 17, 2019, at 18:26, Cy Schubert wrote: > > > > Now that I'm back home, to reply inline re the yacc.h issue. > > > > In message <201906180021.x5I0L2RK057837@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 FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.