Date: Sat, 22 Jul 2017 17:02:13 -0700 From: Mark Millard <markmi@dsl-only.net> To: Bryan Drewery <bdrewery@FreeBSD.org> Cc: Dimitry Andric <dim@FreeBSD.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: amd64 -r321109 -> -r321371 buildworld update failed (spans clang 5 update); error: too few arguments provided to function-like macro invocation; , METAMODE and -j8 was used Message-ID: <DDAAB420-5445-4E5B-B706-3917DF6395CD@dsl-only.net> In-Reply-To: <E1D3387E-1197-4E2D-AD72-F97F898185B7@FreeBSD.org> References: <056C30CC-72B8-41A4-AEAA-64B6B96854DB@dsl-only.net> <E1D3387E-1197-4E2D-AD72-F97F898185B7@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jul-22, at 4:50 PM, Dimitry Andric <dim@FreeBSD.org> wrote:
> On 23 Jul 2017, at 01:32, Mark Millard <markmi@dsl-only.net> wrote:
>>=20
>> My first attempt to update amd64 to a clang 5 based /usr/src
>> failed ( -r321109 -> -r321371 ). Listing just the first
>> error initially:
>>=20
>> --- ToolDrivers/llvm-lib/LibDriver.o ---
>> In file included from =
/usr/src/contrib/llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp:35:
>> =
/usr/obj/amd64_clang/amd64.amd64/usr/src/lib/clang/libllvm/Options.inc:27:=
92: error: too few arguments provided to function-like macro invocation
>> OPTION(prefix_0, "<input>", INPUT, Input, INVALID, INVALID, nullptr, =
0, 0, nullptr, nullptr)
>> =
^
>> /usr/src/contrib/llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp:34:9: =
note: macro 'OPTION' defined here
>> #define OPTION(_1, _2, ID, _4, _5, _6, _7, _8, _9, _10, _11, _12) =
OPT_##ID,
>> ^
>=20
> Yeah, I think this can happen with an incremental build, and if you
> enable MK_CLANG_EXTRAS. There was only one Options.inc file first, in
> $WORLDTMP/usr/src/lib/clang/libllvm, but now there are two different
> ones, under $WORLDTMP/usr/src/lib/clang/libllvm/llvm-lib and
> $WORLDTMP/usr/src/lib/clang/libllvm/llvm-dlltool. This is a rather
> unfortunate change from upstream.
>=20
> I'm unsure what to do here, maybe it is a good idea to explicitly rm
> the incorrect file before make starts to search the directory. Bryan,
> any clues? IIRC there were some other precedents where stale objects
> could get in the way, and would have to be force-deleted before even
> the depend stage?
I've done:
# mv /usr/obj/amd64_clang /usr/obj/amd64_clang_r321109_r321371
before starting a rebuild --in to preserve my
failed-build context in case that record of
the result of the attempt can help.
I also have the script output for the build attempt
that I could extract content from if needed.
It will take some time for the from-scratch rebuild
to even get to the prior failure point, much less
to complete.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DDAAB420-5445-4E5B-B706-3917DF6395CD>