Make clang++ work on Windows

[rok-cesnovar]

Summary:

On Windows with clang++ we get caught in an infinite loop of re-compiling the same files. I exhibited this on clang 9.0.0.

I am investigating it and will try to solve it if I can.

Description:

If CXX=clang++ on Windows make build gets caught in an infinite loop of re-compiling all the files. So the same behavior we exhibited on Travis a while ago.

Reproducible Steps:

• use Windows
• set CXX=clang++
• make build

Current Output:

Infinite loop

Expected Output:

Cmdstan should build normally.

Additional Information:

Current Version:

v2.20.0

[bearloga]

I'm also getting this behavior on macOS 10.14, CmdStan 2.20 and clang-7

[seantalts]

The infinite loop behavior also shows up when those calls fail in certain ways. Try commenting out the dependency include from the main makefile and rerunning make.

…

On Fri, Sep 20, 2019 at 16:33 Mikhail Popov ***@***.***> wrote: I'm also getting this behavior on macOS 10.14, CmdStan 2.20 and clang-7 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#736?email_source=notifications&email_token=AAGET3ETXN2GGVOOSHUKI2LQKUXTHA5CNFSM4IYXLZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7HZZEQ#issuecomment-533699730>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGET3DY6L4JPSIE3H7PHR3QKUXTHANCNFSM4IYXLZCA> .

[seantalts]

@syclik could this be related to the other issues we were seeing before? #668

@bearloga you can try the steps I took in the first post on that issue 668 to see if you have an underlying issue you can fix. especially likely if you recently upgraded Mac OS X or anything like that.

[syclik]

@syclik could this be related to the other issues we were seeing before? #668

Yes, it's possible. I've never run this with clang++ on a Windows box. I'm not good with setup, but if someone can help me log into one, I can do some basic diagnostics and try to see what's causing it.

If I were debugging, I'd start from a clean build and actually clone the library twice.

In the first one, I'd run make build with g++ (or whatever works).

In the second one, I'd run make build with clang++ and break after some time.

Then I'd look for the *.d files scattered everywhere and do file diffs. I honestly don't know where we'll find differences. It could be something in the stl includes or it could be something else. It has to be there. If it's not in the *.d files, that'll tell us something, but I'm not sure what.

Once we find that, we'll need to determine if the dependency files are generated correctly. If they aren't, we can probably tweak the C++ flags or do some sed inside the makefile to force it to behave.

Does that info help at all? @rok-cesnovar or @seantalts, do you have boxes that I can log into?

[rok-cesnovar]

Thanks @syclik

I will try your suggestion. I have a Windows box that is currently not on a static IP (in the process of setting that up but university biroucracy is harder to me than integration :) ).

I can try setting up teamviewer or something in the meantime. But hopefully I can find a fix before that.

@serban-nicusor-toptal can maybe give you access to the AWS instance that is used for Jenkins.

[serban-nicusor-toptal]

I am now spinning up a Windows instance. @rok-cesnovar Can you please send me a mail with @syclik in cc so I can forward the password?

Thanks!

[rok-cesnovar]

Done. Thanks!

[syclik]

Just reporting back... I haven't been able to log in yet; technical difficulties. We'll try again later.

[rok-cesnovar]

I can confirm this actually never worked. At least not on 2.18+. I tried with Clang 7, 8 and 9.
We had other Windows issue before 2.18 so clang++ & Windows never actually worked.

We are recommending RTools and the compiler that comes with it for Windows so I guess its not a pressing issue. Anyways, will get back to this on some rainy day, but for now it goes on the back burner for me. I would leave the issue open if someone wants to explore.

My latest hunch was that it has something to do with clang trying to be MSVC compatible on Windows by default. We at least need to set -target x86_64_windows_gnu in order to use the mingw supplied headers. But even did not lead anywhere.

[rok-cesnovar]

Also Stan Math tests also dont run there with CXX=clang++ on Windows.

[syclik]

Thanks for looking into that. I’m away from a computer for the next few days. When I’m back, I can see if there are different compiler options we use for the dependencies between clang++ and g++. We may not have implemented that logic for Windows (or rather special-cased windows so it works with RTools g++). I’ll try to check when I’m back at a computer.

…

On Sat, Sep 28, 2019 at 6:41 AM Rok Češnovar ***@***.***> wrote: Also Stan Math tests also dont run there with CXX=clang++ on Windows. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#736?email_source=notifications&email_token=AADH6F2IDA7UADH4KFA6TKTQL4YFJA5CNFSM4IYXLZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD72WB7Q#issuecomment-536174846>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADH6FY5R4BQWOWLJLJO24DQL4YFJANCNFSM4IYXLZCA> .