Re: What we have here, ...

--Apple-Mail=_3D9AE865-B3FB-40C0-8ADB-55E47C5A2A92
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Jun 14, 2014, at 9:11 PM, Glen Barber <[e-mail]> wrote:

> On Sat, Jun 14, 2014 at 09:03:51PM -0600, Warner Losh wrote:
>>=20
>> On Jun 14, 2014, at 8:51 PM, Glen Barber <[e-mail]> wrote:
>>=20
>>> Is a failure to build head/ with high make(1) -j values.  Again.
>>=20
>> There=92s likely a dozen or more of these lurking in the tree. Ian=92s =
last set
>> of patches squashed many of the ones in lib, but I=92ve not done a =
careful
>> audit of the i18n code.
>>=20
>=20
> Ok, thanks for the info.  I'm a bit unclear on how the parallelization
> stuff in share/ actually works, but I'm happy to help crowbar at =
things.

I haven=92t even looked, to be honest...

>>> With empty /usr/obj, I have been seeing strange build failures on =
head/
>>> with high -jN values, but even as low as -j10.  The machine used to
>>> build snapshots of head/ and stable/ branches has been using -j48 =
for
>>> several months without issue, so I am certain this is a recent (<=3D1
>>> month) issue.
>>>=20
>>> Of all things, it looks like fonts are failing to build, giving the
>>> following error:
>>>=20
>>> --- MACGUJARATI.esdb ---
>>> NAME is mandatory.
>>> ENCODING is mandatory.
>>> *** [MACGUJARATI.esdb] Error code 1
>>> make[6]: stopped in /usr/src/share/i18n/esdb/APPLE
>>>=20
>>> Is anyone else seeing this with empty MAKEOBJDIR ?
>>=20
>> I haven=92t seen it, but in -j races, that means approximately zilch=85=
=20
>>=20
>=20
> Yeah.  To be honest, it's the similar situation I emailed you =
privately
> about a few weeks ago with the race in rescue/ that makes no sense.  =
So
> while I don't entirely trust make(1) reporting what blew up, unlike =
the
> issue in rescue/, the 'NAME is mandatory' error has been about 90%
> reproducible between both amd64 and i386.  (Without being able to =
build
> at least amd64, I cannot test other architectures.  Useless data =
point,
> I know.)

Yea, that turns out to be a cascade of dozens of errors based on a file =
being
empty=85. The error reporting is correct, you just have to thread it =
back a ways.
Sure would be nice to have a tool that would remove the clutter from the =
make
that we=92ve grown when you=92re looking for a specific thing.

>>> I won't be able to reproduce the issue with log output until at =
least
>>> Monday, since I'm running the head/ builds with the '-jN' halved to =
24,
>>> which so far seems to have made a difference.
>>=20
>> How many cores in this box of yours?
>>=20
>=20
> 48.

I only have 12 (or 24 if I configure for threading) :).  That might make =
a big difference.

Warner

--Apple-Mail=_3D9AE865-B3FB-40C0-8ADB-55E47C5A2A92
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJTnd5qAAoJEGwc0Sh9sBEABXAQANSUjiaYsOla9CFk47wW71O6
0DK32Jw41MnjhIcqYZmfRGCgex2ZeHO3oLzdbrjfJnm5Bd6lPsLE9Bl6jL0EVkAT
Io7DRkmnNDqsm4XqmoDVmOEjm/E7HsrojHWJMPKQIVVO0OMzUoN6h6PnT+E8t6El
rfuwgmfzpY7pbeUg3b201EvFGPmKQqHCmEGJsITifRXxlhSbkr8M+/vUgyVty7U6
LB9UVs0D/Rv0ksh/dZiGjVYPCHnZj2YFRMN+sb1UvYFLCUeqtNjAq2uR+nzXRdFg
xqC87D/BN6M2l3utCrbLRBHoZAea6OKXq0IAX2CAV1J7FasEzKwSECrRncqS37vK
Mle7gVlbblKOZJogy04XGqxJlPjYe22I7sw/FYdq/bYTu+zbhmm6uUuCweV+VNU1
/UhjufuRAk2/frnQu2+sSXmPfI7kZHNHc1naAmv5AI5yRXC7svD+GQTC2uTxI7fr
GX25nHSYMSBQvtLtpLGew8xFAkza4UJloT3Dxy/k0CPx15BxkO9qiLw2LpITAbJ2
ouffb6wD93H94pLP1ImCNlbVC1odkdIsCxwGcbS1kn7R624cYhDCPifow2EqjBbD
L8cc5FL8bODFmxuYCm5tzB41GWA4jX+A1e+iAY/d5RQAi62RLGPnOqSnPWPfkPC/
4SkSDyNPcPp8TfXGPHJX
=Py5c
-----END PGP SIGNATURE-----

--Apple-Mail=_3D9AE865-B3FB-40C0-8ADB-55E47C5A2A92--