Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Jun 2019 09:06:05 -0700
From:      Bryan Drewery <bdrewery@FreeBSD.org>
To:        Ian Lepore <ian@freebsd.org>, Cy Schubert <Cy.Schubert@cschubert.com>, freebsd-current@freebsd.org, Michael Tuexen <tuexen@freebsd.org>, "koobs@freebsd.org" <koobs@FreeBSD.org>
Subject:   Re: error: yacc.h: No such file or directory
Message-ID:  <d30ff7ea-2aa4-8a46-6c87-89302201005c@FreeBSD.org>
In-Reply-To: <d1517bf378c1acaa3c8a24aca5c5cf4e7e68ad7e.camel@freebsd.org>
References:  <0737312F-50AE-4526-B201-E62DB8949612@freebsd.org> <4b1f9f81-6463-c1bd-30a9-14aed49fc038@FreeBSD.org> <061907F0-D8FC-4AEA-AA8C-5928A09425E9@freebsd.org> <BDC50C70-1F9F-46C3-95DE-24E234FF7FB2@cschubert.com> <d1517bf378c1acaa3c8a24aca5c5cf4e7e68ad7e.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CiXZOgDqIE31gCRDmjli5ggIsrZ8ojezM
Content-Type: multipart/mixed; boundary="2HmMU8eYQAp2P2JR6qwZFL6WJV51hbHFK";
 protected-headers="v1"
From: Bryan Drewery <bdrewery@FreeBSD.org>
To: Ian Lepore <ian@freebsd.org>, Cy Schubert <Cy.Schubert@cschubert.com>,
 freebsd-current@freebsd.org, Michael Tuexen <tuexen@freebsd.org>,
 "koobs@freebsd.org" <koobs@FreeBSD.org>
Message-ID: <d30ff7ea-2aa4-8a46-6c87-89302201005c@FreeBSD.org>
Subject: Re: error: yacc.h: No such file or directory
References: <0737312F-50AE-4526-B201-E62DB8949612@freebsd.org>
 <4b1f9f81-6463-c1bd-30a9-14aed49fc038@FreeBSD.org>
 <061907F0-D8FC-4AEA-AA8C-5928A09425E9@freebsd.org>
 <BDC50C70-1F9F-46C3-95DE-24E234FF7FB2@cschubert.com>
 <d1517bf378c1acaa3c8a24aca5c5cf4e7e68ad7e.camel@freebsd.org>
In-Reply-To: <d1517bf378c1acaa3c8a24aca5c5cf4e7e68ad7e.camel@freebsd.org>

--2HmMU8eYQAp2P2JR6qwZFL6WJV51hbHFK
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Yes this is likely due to my changes as I removed headers from one of
the forced dependency lists. I'll look at it in a bit.
(I ran several clean and incremental builds without fault but yeah it
could be a race.)
Note my breakage likely only affected world and not kernel so any
opt_*.h isn't new.

Bryan

On 6/18/2019 6:53 AM, Ian Lepore wrote:
> On Tue, 2019-06-18 at 06:45 -0700, Cy Schubert wrote:
>> On June 18, 2019 6:24:36 AM PDT, Michael Tuexen <tuexen@freebsd.org>
>> wrote:
>>>> On 18. Jun 2019, at 12:56, Kubilay Kocak <koobs@FreeBSD.org>
>>>> wrote:
>>>>
>>>> On 18/06/2019 5:42 pm, Michael Tuexen wrote:
>>>>> Dear all,
>>>>> I'm trying to run
>>>>> sudo make buildworld
>>>>> in a directory with r349168.
>>>>> The result is:
>>>>> cc  -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static
>>>
>>> -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb=20
>>> -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv=20
>>>  -g
>>> -MD  -MF.depend.lex.o -MTlex.o -std=3Dgnu99   =20
>>> -I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/in
>>> clude
>>> -c lex.c -o lex.o
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error:
>>>>> yacc.h: No
>>>
>>> such file or directory
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function
>>>>> 'yylex':
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN'
>>>
>>> undeclared (first use in this function)
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each
>>>
>>> undeclared identifier is reported only once
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each
>>>
>>> function it appears in.)
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval'
>>>
>>> undeclared (first use in this function)
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM'
>>>
>>> undeclared (first use in this function)
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME'
>>>
>>> undeclared (first use in this function)
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error:
>>>>> 'R_ENCODING'
>>>
>>> undeclared (first use in this function)
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error:
>>>>> 'R_VARIABLE'
>>>
>>> undeclared (first use in this function)
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error:
>>>>> 'R_DEFCSID'
>>>
>>> undeclared (first use in this function)
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error:
>>>>> 'R_INVALID'
>>>
>>> undeclared (first use in this function)
>>>>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error:
>>>>> 'L_STRING'
>>>
>>> undeclared (first use in this function)
>>>>> *** Error code 1
>>>>> Stop.
>>>>> make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static
>>>>> *** Error code 1
>>>>> Stop.
>>>>> make[2]: stopped in /usr/home/tuexen/head
>>>>> *** Error code 1
>>>>> Stop.
>>>>> make[1]: stopped in /usr/home/tuexen/head
>>>>> *** Error code 1
>>>>> Stop.
>>>>> make: stopped in /usr/home/tuexen/head
>>>>> This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does
>>>>> not
>>>
>>> resolve the issue.
>>>>> Any idea what is going wrong?
>>>>> Best regards
>>>>> Michael
>>>>
>>>> Have seen another report on Twitter yesterday. Didn't see a full
>>>
>>> build log, but theirs was had apparently without -j, apparently on
>>> June
>>> 14 sources:
>>>>
>>>> Error:
>>>> /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file
>>>> not
>>>
>>> found
>>>>
>>>> Have not heard back from them whether it continued after trying
>>>> -j2
>>>
>>> but I did ask them to hit up freebsd-current if it continued to be
>>> an
>>> issue
>>> OK, I started the build again with -j 2 and it seems that the
>>> problem
>>> does not occur.
>>>
>>> Since I have been using make buildworld without -j n in the past on
>>> that machine, the
>>> problem seems to be introduced recently. Any idea what is the cause
>>> of
>>> the problem?
>>>
>>> Best regards
>>> Michael
>>>>
>>>
>>> _______________________________________________
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to
>>> "freebsd-current-unsubscribe@freebsd.org"
>>
>> This is a generated file. It would appear the make target to build
>> yacc.h hadn't run yet by the time the target that consumed the file
>> ran.
>>
>> I had a similar problem on Sunday. It wasn't yacc.h but some other
>> file, I cannot remember which. It occurred during one of four
>> buildworlds. Simply restarting the failed buildworld was enough to
>> resolve it.
>>
>> My hypothesis is a buildworld race. I wonder if some of the recent
>> (over the last week or two) makefile changes exacerbated this issue.
>>
>>
>=20
> Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) that
> were all somehow related to dependency processing in the build.  I
> don't know the details, just remember seeing some commits about that.
>=20
> -- Ian
>=20


--=20
Regards,
Bryan Drewery


--2HmMU8eYQAp2P2JR6qwZFL6WJV51hbHFK--

--CiXZOgDqIE31gCRDmjli5ggIsrZ8ojezM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEE+Rc8ssOq6npcih8JNddxu25Gl88FAl0JC+1fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5
MTczQ0IyQzNBQUVBN0E1QzhBMUYwOTM1RDc3MUJCNkU0Njk3Q0YACgkQNddxu25G
l88Hywf/c+cUzt6WajX9rpYEgxlqmPwSPdZgCd0GtPVfxiU0PGTnWD7WC5AtocXy
c1JlLeHXTOX9fda3IX/isodiVoufRwERp0D/zjjUJ8JjaKXUBvCiQZKTwxQSIt6P
8cjonOkCo6GUvzHKFx87LNA7DZBjHbH1cH5ufjuZQlXthmKc+bEzZH/Xd2HFo3CZ
PTQkEQuDK1z8L6J2yAx5f2Zcz14UAgFTNLE/1nNRbw75ahFR22UknOGLqfIDM6ZI
r9JiQSHhVXpyWD/1tNvJmRqiw17GcM96OlbaAqF3utUu7xUvkRvtfdAMRoRAbfRo
EnBvrBw1X9b5u786s588haWgqqFYHQ==
=ExTd
-----END PGP SIGNATURE-----

--CiXZOgDqIE31gCRDmjli5ggIsrZ8ojezM--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d30ff7ea-2aa4-8a46-6c87-89302201005c>