Date: Wed, 5 Jun 2013 16:20:26 -0500 From: Brooks Davis <brooks@freebsd.org> To: dt71@gmx.com Cc: freebsd-current@freebsd.org Subject: Re: another external compiler topic Message-ID: <20130605212026.GA20976@lor.one-eyed-alien.net> In-Reply-To: <51AFA389.40607@gmx.com> References: <51AF891A.3080906@gmx.com> <20130605193122.GD18357@lor.one-eyed-alien.net> <51AFA389.40607@gmx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 05, 2013 at 10:46:01PM +0200, dt71@gmx.com wrote:
> On 06/05/2013 21:31, Brooks Davis wrote:
> > My first reaction is that your configuration is so far beyond anything
> > that is actually documented as working you're going to be mostly on your
> > own.
>=20
> Why?
We can not possibly support all of the effectively infinite numbers of
knobs and switch you can set in the build process. If you want to veer
far outside the lines of well documented routes, it's up to you to find
and fix problems.
> > First off I assume that since you posted to freebsd-current@ that you
> > are running the latest head.
>=20
> Yes:
> > On Wed, Jun 05, 2013 at 08:53:14PM +0200, dt71@gmx.com wrote:
> >> Installed system revision: 251046.
> >> Checked out source tree revision: 251352.
>=20
> > Setting CC, CPP, and CXX except in the environment isn't supported and
> > can't work for cross build cases. It looks like your avoiding those
> > cases (but more on your wrapper script later), but this does put you in
> > uncharted land.
>=20
> Now compiling with CC, CPP and CXX only in the environment (and XCC, XCPP=
and XCXX in make.conf).
If you XCC, XCPP, and XCXX you may not need CC, CPP, and CXX at all,
though your environment is weird enough I won't assert that.
> > I see that WITHOUT_KERBEROS is not set here. Was it ever? Migration
> > from a WITHOUT_KERBEROS system to a WITH_KERBEROS system is known to be
> > broken which might explain your breakage in the libkrb5 build.
>=20
> Yes, WITHOUT_KERBEROS was set once in the past, but that was only so mult=
iple re-buildworld and re-installworld iterations ago.
I've not experienced the kerberos failures so I'm not sure if this is
one or not. I suspect there is another error further up in your output,
but it's hard to say. If this is a parallel build there have been
reports of kerberos build failures with high levels of parallelism. It
may be that something you've disabled results in the presumed makefile
bug being easier to trigger.
> >> When building the system that is currently installed, the following "c=
ompiler" was used:
> >> =3D=3D=3D=3D=3D=3D=3D /path/to/clang begins =3D=3D=3D=3D=3D=3D=3D
> >> #!/bin/sh
> >> /path/to/real/clang "$@" || /path/to/real/clang --sysroot=3D/usr/obj/u=
sr/src/tmp "$@"
> >> =3D=3D=3D=3D=3D=3D=3D /path/to/clang ends =3D=3D=3D=3D=3D=3D=3D
> >
> > This has got to corrupt your build. I can't imagine anything staying
> > working for long given that many translation units will compile with
> > the system headers and then get linked to something compiled with the
> > headers from the source tree.
>=20
> I forgot to mention that after re-buildworld-ing and re-installworld-ing =
with the script, I redid the whole process again without the script (at whi=
ch point the sysroot argument was not required anymore, until the next head=
er update).
I guess that could work, but it still sounds like a recipe for disaster.
> >> Also, the following patch was applied to the source tree:
> >> =3D=3D=3D=3D=3D=3D=3D diff begins =3D=3D=3D=3D=3D=3D=3D
> >> Index: Makefile.inc1
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> --- Makefile.inc1 (revision 251352)
> >> +++ Makefile.inc1 (working copy)
> >> @@ -722,7 +722,7 @@
> >> ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown \
> >> date echo egrep find grep id install ${_install-info} \
> >> ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
> >> - rm sed sh sysctl test true uname wc ${_zoneinfo}
> >> + rm sed sh sysctl test true uname wc ${_zoneinfo} btxld ls mv cp dd
> >>
> >> #
> >> # distributeworld
> >> Index: usr.bin/xlint/llib/Makefile
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> --- usr.bin/xlint/llib/Makefile (revision 251352)
> >> +++ usr.bin/xlint/llib/Makefile (working copy)
> >> @@ -9,9 +9,9 @@
> >> CLEANFILES+=3D ${LIBS}
> >>
> >> llib-lposix.ln: llib-lposix
> >> - ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
> >> + CC=3D${CC:Q} ${LINT} ${LINTFLAGS} -Cposix ${.ALLSRC}
> >>
> >> llib-lstdc.ln: llib-lstdc
> >> - ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
> >> + CC=3D${CC:Q} ${LINT} ${LINTFLAGS} -Cstdc ${.ALLSRC}
> >>
> >> .include <bsd.prog.mk>
> >> =3D=3D=3D=3D=3D=3D=3D diff ends =3D=3D=3D=3D=3D=3D=3D
> >
> > What do these patches work around?
>=20
> The 1st hunk works around an installkernel issue: in some cases (unknown,=
but seemingly related to header updates), installkernel seems to involve s=
ome compiling, "cp"ing, "btxld"ing, etc..
Hmm, that seems weird. I've never seen that.
> Without the 2nd hunk, the lint program would call "cc", which does not ex=
ist (ie., there is no /usr/bin/cc, but there is a ${CC}).
This sounds like a bug.
-- Brooks
--DocE+STaALJfprDB
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iD8DBQFRr6uaXY6L6fI4GtQRAgb+AKCGx6gJ8/jM99dpBKoDklkM2jBNHwCgnN4A
pj4DjdkxJfjGnYvQr2ZO2ms=
=XYQZ
-----END PGP SIGNATURE-----
--DocE+STaALJfprDB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130605212026.GA20976>