Re: r111 build error

On Wed, 12 Dec 2018 at 07:35, Lev Serebryakov <lev_at_freebsd.org> wrote:
>
> On 12.12.2018 14:59, Dimitry Andric wrote:
>
> >>>> ld: error: undefined symbol: clang::CallExpr::getLocStart() const
> >>>>>>> referenced by MacOSXAPIChecker.cpp:86
> >>>>>>> (/usr/src/contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/MacOSXAPIChecker.cpp:86)
> >>>>>>> MacOSXAPIChecker.o:((anonymous
> >>>>>>> namespace)::MacOSXAPIChecker::CheckDispatchOnce(clang::ento::CheckerContext&,
> >>>>>>> clang::CallExpr const*, llvm::StringRef) const) in
> >>>>>>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> >
> > Any ideas on how to reproduce this build failure?  I have run multiple
> > universe builds before committing this update, and I never saw any error
> > which resembles the above.
>  rm -rf /usr/obj/src helps to get rid of this error. I've had /usr/obj
> from previous version (but I didn't use -DNO_CLEAN!).

This sounds like a similar issue to one I fixed in r341796 after the
most recent wpa update - there are a few cases of source changes that
are not handled well by .depend files. While we could take this to
root cause I think the most expedient fix is probably just to check
for evidence of clang 6 in the object tree, and rm the .depend files
and objects if found. Checking for clang 6 can be done by grepping for
a file removed in the clang 7 update. This approach is rather hacky,
but has allowed builds with -DNO_CLEAN to succeed for the last year
and a half or so, and the hacks do not need to persist indefinitely.

It would look something like:
_at_if [ -e "${OBJTOP}/lib/clang/.../.depend.foo.o" ] && \
    egrep -q 'some/file/removed/in/clang7.c' \
    ${OBJTOP}/lib/clang/.../.depend.foo.o; then \
        echo "Removing stale clang 6 dependencies and objects"; \
        find ${OBJTOP}/lib/clang -name '.depend.*' -o -name '*.o' -delete \
fi

I might move these cleanup hacks out into a standalone shell script to
make it easier to test and maintain them.