[llvm-dev] darwin bootstrap failure

[Don Hinton via llvm-dev]

On Sun, Oct 15, 2017 at 10:16 AM, Don Hinton <hintonda at gmail.com> wrote:

> On Sun, Oct 15, 2017 at 10:03 AM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>
>> On Sun, Oct 15, 2017 at 12:40 PM, Don Hinton <hintonda at gmail.com> wrote:
>> > On Sun, Oct 15, 2017 at 8:34 AM, Aaron Ballman <aaron at aaronballman.com>
>> > wrote:
>> >>
>> >> FWIW, most of the ones I was fixing up were guarded by NDEBUG instead
>> >> of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link
>> >> errors for me -- the only one I struggled with was
>> >> AsmMatcherEmitter::run(). But it sounds like you're saying switching
>> >> the configuration type in MSVC from Debug to Release would have
>> >> possibly caused issues as well?
>> >
>> >
>> > This is what I believe is going on -- hope this isn't too convoluted...
>> >
>> > I don't know how you invoked cmake, but the generators for VS and Xcode
>> > support multiple configurations, allowing you to delay choosing the
>> build
>> > type and implicitly setting CMAKE_BUILD_TYPE=None.
>> >
>> > If CMAKE_BUILD_TYPE isn't passed or doesn't include "debug",
>> CMakeLists.txt
>> > assumes it's a release build, turns off both asserts and dump methods,
>> and
>> > generates llvm-config.h without defining LLVM_ENABLE_DUMP.  Since my
>> change
>> > removed the NDEBUG test for most dump definitions, they were #ifdef'd
>> away.
>> > While it's possible to override this behavior by passing
>> > -DLLVM_ENABLE_ASSERTIONS or -DLLMV_FORCE_ENABLE_DUMP, you don't seem to
>> have
>> > done that.
>> >
>> > So, when a Debug build was later selected, llvm-config.h had already
>> been
>> > written without defining LLVM_ENABLE_DUMP, and since table-gen didn't
>> have
>> > the fix, it assumed the dump methods were available when it didn't see
>> > -DNEBUG on the command line -- hence the linking errors.
>> >
>> > So, setting LLVM_ENABLE_DUMP at configuration time won't work in this
>> case,
>> > and I'm leaning toward removing it completely.
>>
>> Ah, okay, I see what the issue is. Thank you for the explanation!
>>
>> > Jack's issue involved removing -DNDEBUG in a script for Release builds.
>> > While it caused the same linking issues you saw, it really didn't have
>> > anything to do with the configuration issue you uncovered.  Had I seen
>> any
>> > other errors, I would have rolled it back yesterday, but as you've
>> said, the
>> >bots were clean wrt this change.
>>
>> I was surprised that this didn't make any MSVC bots go red. The
>> default behavior I see is that I run cmake and I get a Debug build
>> without fiddling with anything in MSVC, unless I specify cmake options
>> to do a release build.
>>
>
> Since it creates multiple ones, it must be selecting the Debug
> configuration by default -- it has to pick something.  But that has nothing
> to do with the cmake variables we set in CMakeList.txt.
>

Looks like they specify everything explicitly:

cmake -G Ninja ../llvm -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DLLVM_ENABLE_ASSERTIONS=True -DLLVM_LIT_ARGS='-v'
-DCMAKE_INSTALL_PREFIX=../stage1.install -DLLVM_ENABLE_ASSERTIONS=ON
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171015/923c6379/attachment.html>