[llvm-dev] LLVM 3.9.1 build race?

[Belal, Awais via llvm-dev]

Hi Justin,

> This looks like something I fixed recently, in r290271:
...
...
> The tablegen build adopted USES_TERMINAL for this same reason in
>   r280748.

I applied the 2 patches you mentioned above on my 3.9.1 tree and although the build seems to go along nicely than the earlier reported symptoms I can still see LLVMSupport being built a bit too many times than expected.

$ cat log.do_compile | grep "Built target" | cut -d "]" -f2 | grep Support
 Built target LLVMSupport
 Built target LLVMSupport
 Built target LLVMSupport
 Built target LLVMSupport

Now, I would expect to see LLVMSupport being built only twice, once for the NATIVE build and the other for the target. I dug through the whole log and LLVMSupport gets built twice for the NATIVE side and twice for the target side, is this the intended behavior? Would it be possible for you to share a cross build log with me so I can compare what I might be doing wrong?

And hey, the above mentioned patches did fix 3 out of the 4 "warning: jobserver unavailable: using -j1.  Add `+' to parent make rule." messages I was getting. Now I only get this warning when the native llvm-config target starts building.

Thanks a lot for all the help!

BR,
Awais

________________________________________
From: Justin Bogner <justin at justinbogner.com> on behalf of Justin Bogner <mail at justinbogner.com>
Sent: Wednesday, January 25, 2017 11:31 PM
To: Belal, Awais via llvm-dev
Cc: Belal, Awais; Tom Stellard
Subject: Re: [llvm-dev] LLVM 3.9.1 build race?

"Belal, Awais via llvm-dev" <llvm-dev at lists.llvm.org> writes:
> I am building LLVM 3.9.1 using the Yocto build system for a cross
> build. The compiled bins/libs work totally fine on the target machine
> however there seems to be an intermittent race condition during the
> build which causes a build failure. On the failed builds I usually see
> things being linking/compiling twice e.g.
 ...
> and from the above mentioned example the build failed with
>
>
> ../../lib/libLLVMSupport.a(Process.cpp.o): In function
> `llvm::sys::Process::GetRandomNumber()':
> Process.cpp:(.text._ZN4llvm3sys7Process15GetRandomNumberEv+0x70):
> undefined reference to `llvm::sys::TimeValue::now()'
> collect2: error: ld returned 1 exit status

This looks like something I fixed recently, in r290271:

  commit 8bddda3652b36619cc8cd916c33d38c9cd41f024
  Author: Justin Bogner <mail at justinbogner.com>
  Date:   Wed Dec 21 21:19:00 2016 +0000

    cmake: Don't build llvm-config and tblgen concurrently in cross builds

    This sets USES_TERMINAL for the native llvm-config build, so that it
    doesn't run at the same time as builds of other native tools (namely,
    tablegen). Without this, if you're very unlucky with the timing it's
    possible to be relinking libSupport as one of the tools is linking,
    causing a spurious failure.

    The tablegen build adopted USES_TERMINAL for this same reason in
    r280748.

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290271 91177308-0d34-0410-b5e6-96231b3b80d8

Tom: if we do a 3.9.2, it's probably worth pulling this change in.

> I also see exactly 4 instances of "warning: jobserver unavailable:
> using -j1.  Add `+' to parent make rule." and this was reported at
> https://llvm.org/bugs/show_bug.cgi?format=multiple&id=23328 quite some
> time ago. Has there been any movement on this? Can the mentioned
> warning cause such a trouble? I doubt that because the warning appears
> in successful builds as well but I'd love to hear expert opinion on
> this.
>
>
> NATIVE builds are done for the host which is then utilized for
> generating the target binaries, correct? If that is so, what can cause
> multiple builds for the NATIVE system?
>
>
> We're building with CMake with the "Unix Makefiles" generator prior to
> this we were building 3.7.1 using autotools and never saw such an
> issue. GCC version is 5.4.0 on both instances with GNU Make at
> 4.1. Any pointers/help would be highly appreciated.
>
>
> BR,
> Awais
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev