Date: Sun, 23 Jul 2017 17:27:35 -0700 From: Mark Millard <markmi@dsl-only.net> To: Dimitry Andric <dim@FreeBSD.org>, Bryan Drewery <bdrewery@FreeBSD.org> Cc: 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: <77819047-45D4-4CA4-BF17-2A00FE21E32B@dsl-only.net> In-Reply-To: <3EF869EB-ADB6-455B-8725-2E42C73B27EB@FreeBSD.org> References: <056C30CC-72B8-41A4-AEAA-64B6B96854DB@dsl-only.net> <E1D3387E-1197-4E2D-AD72-F97F898185B7@FreeBSD.org> <DDAAB420-5445-4E5B-B706-3917DF6395CD@dsl-only.net> <3EF869EB-ADB6-455B-8725-2E42C73B27EB@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jul-22, at 5:09 PM, Dimitry Andric <dim at FreeBSD.org> wrote: > On 23 Jul 2017, at 02:02, Mark Millard <markmi at dsl-only.net> wrote: >> >> 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: >>>> >>>> My first attempt to update amd64 to a clang 5 based /usr/src >>>> failed ( -r321109 -> -r321371 ). Listing just the first >>>> error initially: >>>> >>>> --- 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, >>>> ^ >>> >>> 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. >>> >>> 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. > > What you could try with the old objdir is: > > rm /usr/obj/amd64_clang/amd64.amd64/usr/src/lib/clang/libllvm/Options.inc > > then doing another incremental build. I think that will work. Comparing the Options.inc list from a failed cross build update to -r321371 to one that has been rebuilt: Note rebuilt yet (I deliberately did not clean out any old Options.inc files first): # find /usr/obj/cortexA53_clang/ -name Options.inc -print | sort /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/lib/clang/libclang/clang/Driver/Options.inc /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/lib/clang/libllvm/Options.inc /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/src/lib/clang/libclang/clang/Driver/Options.inc /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/src/lib/clang/libllvm/Options.inc /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/src/lib/clang/libllvm/llvm-dlltool/Options.inc /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/src/lib/clang/libllvm/llvm-lib/Options.inc /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/src/usr.bin/clang/lld/ELF/Options.inc /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/usr.bin/clang/lld/ELF/Options.inc vs. rebuilt (with first cleaning out sufficient Options.inc files): # find /usr/obj/powerpc64vtsc_clang_altbinutils/ -name Options.inc -print | sort /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/libclang/clang/Driver/Options.inc /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/libllvm/llvm-dlltool/Options.inc /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/libllvm/llvm-lib/Options.inc /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/src/lib/clang/libclang/clang/Driver/Options.inc /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/src/lib/clang/libllvm/llvm-dlltool/Options.inc /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/usr/src/lib/clang/libllvm/llvm-lib/Options.inc /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/usr.bin/clang/lld/ELF/Options.inc It looks like all the following are "old only": . . ./usr/src/lib/clang/libllvm/Options.inc . . ./usr/src/tmp/usr/src/lib/clang/libllvm/Options.inc . . ./usr/src/tmp/usr/src/usr.bin/clang/lld/ELF/Options.inc And comparing the rebuilt to something that has not had an attempted update to a clang 5 version at all: # find /usr/obj/armv7_clang/ -name Options.inc -print | sort /usr/obj/armv7_clang/arm.armv6/usr/src/lib/clang/libclang/clang/Driver/Options.inc /usr/obj/armv7_clang/arm.armv6/usr/src/lib/clang/libllvm/Options.inc /usr/obj/armv7_clang/arm.armv6/usr/src/tmp/usr/src/lib/clang/libclang/clang/Driver/Options.inc /usr/obj/armv7_clang/arm.armv6/usr/src/tmp/usr/src/lib/clang/libllvm/Options.inc /usr/obj/armv7_clang/arm.armv6/usr/src/usr.bin/clang/lld/ELF/Options.inc It looks like all the following are "old only": . . ./usr/src/lib/clang/libllvm/Options.inc . . ./usr/src/tmp/usr/src/lib/clang/libllvm/Options.inc === Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?77819047-45D4-4CA4-BF17-2A00FE21E32B>