[config] Need help with clang config
I've just added travis support to Boost.Config, the problem is that there are a large number of clang failures that I simply don't know how to fix, see: https://travis-ci.org/boostorg/config The errors occur because clang chokes on libstdc++ code, so while <regex> exists (for example), clang won't parse it. Any ideas anyone? Thanks in advance, John. --- This email has been checked for viruses by AVG. http://www.avg.com
On Thu, 2017-05-18 at 20:06 +0100, John Maddock via Boost wrote:
I've just added travis support to Boost.Config, the problem is that there are a large number of clang failures that I simply don't know how to fix, see: https://travis-ci.org/boostorg/config
The errors occur because clang chokes on libstdc++ code, so while <regex> exists (for example), clang won't parse it. Any ideas anyone?
On my PR from two months ago, I never saw a problem with regex with travis. This ran the tests for both libc++ and libstdc++, but it used libc++ from gcc 5. However, there is a problem with the tests when using older c++ versions(such as c++11 or c++03), as the header still exists even though it is not valid. So I only tested the very latest versions. Ideally the header test should check for the classes someone would expect in the header, which would avoid this problem. I also disabled the several tests as they were broken on different platforms: https://github.com/boostorg/config/pull/129/files#diff-15547c54d3d4898a882b4... 7b3cee381R70
Thanks in advance, John.
--- This email has been checked for viruses by AVG. http://www.avg.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo st
John Maddock wrote:
I've just added travis support to Boost.Config, the problem is that there are a large number of clang failures that I simply don't know how to fix, see: https://travis-ci.org/boostorg/config
The errors occur because clang chokes on libstdc++ code, so while <regex> exists (for example), clang won't parse it. Any ideas anyone?
The configuration with the built-in clang++ in C++11 mode should just be disabled; the default libstdc++ on Travis is 4.6 and is too broken for any serious C++11 work. Clang 3.5 uses libstdc++ 4.8, for which Config probably disables <regex> as known non-working, which is why it passes. Clang 3.6 and above on that configuration use libstdc++ 4.9, which we probably assume is working, but apparently not on Clang (it doesn't like the constant expression 1 << 32.) So we should disable <regex> 4.9 on Clang. This: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905 says that _GLIBCXX_REGEX_STATE_LIMIT is defined on 5 and _GLIBCXX_RELEASE is defined on 7, although I see that we have our own macro BOOST_LIBSTDCXX_VERSION, so we could just use that.
On 5/18/2017 5:40 PM, Peter Dimov via Boost wrote:
John Maddock wrote:
I've just added travis support to Boost.Config, the problem is that there are a large number of clang failures that I simply don't know how to fix, see: https://travis-ci.org/boostorg/config
The errors occur because clang chokes on libstdc++ code, so while <regex> exists (for example), clang won't parse it. Any ideas anyone?
The configuration with the built-in clang++ in C++11 mode should just be disabled; the default libstdc++ on Travis is 4.6 and is too broken for any serious C++11 work.
Clang 3.5 uses libstdc++ 4.8, for which Config probably disables <regex> as known non-working, which is why it passes.
Clang 3.6 and above on that configuration use libstdc++ 4.9, which we probably assume is working, but apparently not on Clang (it doesn't like the constant expression 1 << 32.)
So we should disable <regex> 4.9 on Clang. This:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905
says that _GLIBCXX_REGEX_STATE_LIMIT is defined on 5 and _GLIBCXX_RELEASE is defined on 7, although I see that we have our own macro BOOST_LIBSTDCXX_VERSION, so we could just use that.
I have always had a difficult problem trying to figure out with which version of gcc/libstdc++ a particular version of clang will work. I have asked about this on the clang developers mailing list but received no answer. If there is any information about this anywhere I would surely like to know where it is.
I have always had a difficult problem trying to figure out with which version of gcc/libstdc++ a particular version of clang will work. I have asked about this on the clang developers mailing list but received no answer. If there is any information about this anywhere I would surely like to know where it is.
Well.... the answer it appears is trial and error, here's what I have so far (which is enough to get the tests passing for now): clang 5: * No <regex> prior to gcc-5.x * No thread_local prior to gcc-4.8.x (ABI/linker issues) Clang 3.x: * No <future>, <mutex>, <condition_variable> or <chrono> prior to gcc 4.8 (these are all failures to compile <chrono>) There may be other issues with old clang and newer gcc, but I haven't tested that combination yet. Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com
On 5/20/2017 3:54 AM, John Maddock via Boost wrote:
I have always had a difficult problem trying to figure out with which version of gcc/libstdc++ a particular version of clang will work. I have asked about this on the clang developers mailing list but received no answer. If there is any information about this anywhere I would surely like to know where it is.
Well.... the answer it appears is trial and error, here's what I have so far (which is enough to get the tests passing for now):
clang 5: * No <regex> prior to gcc-5.x * No thread_local prior to gcc-4.8.x (ABI/linker issues)
Clang 3.x: * No <future>, <mutex>, <condition_variable> or <chrono> prior to gcc 4.8 (these are all failures to compile <chrono>)
There may be other issues with old clang and newer gcc, but I haven't tested that combination yet.
Thanks. I still find problems using clang 3.x-4.0 even with latest versions of gcc. On Windows it is mostly linking problems, but the clang developers on the mailing list really don't care about clang targeting gcc on Windows. But even on Linux I run into problems where gcc "just works". I have a strong feeling that clang needs to distribute its own headers and own standard library ( libc++ ) in order to work correctly and reliably as a compiler. Hopefully the clang developers will understand this for the future also.
Thanks, John.
Thanks. I still find problems using clang 3.x-4.0 even with latest versions of gcc. On Windows it is mostly linking problems, but the clang developers on the mailing list really don't care about clang targeting gcc on Windows. But even on Linux I run into problems where gcc "just works". I have a strong feeling that clang needs to distribute its own headers and own standard library ( libc++ ) in order to work correctly and reliably as a compiler. Hopefully the clang developers will understand this for the future also.
+1 on that. If you run into any roadbumps that the current Boost.Config doesn't address let me know. John. --- This email has been checked for viruses by AVG. http://www.avg.com
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener via Boost Sent: 22 May 2017 17:35 To: boost@lists.boost.org Cc: Edward Diener Subject: Re: [boost] [config] Need help with clang config
On 5/20/2017 3:54 AM, John Maddock via Boost wrote:
I have always had a difficult problem trying to figure out with which version of gcc/libstdc++ a particular version of clang will work. I have asked about this on the clang developers mailing list but received no answer. If there is any information about this anywhere I would surely like to know where it is.
Thanks. I still find problems using clang 3.x-4.0 even with latest versions of gcc. On Windows it is mostly linking problems, but the clang developers on the mailing list really don't care about clang targeting gcc on Windows. But even on Linux I run into problems where gcc "just works".
I have a strong feeling that clang needs to distribute its own headers and own standard library ( libc++ ) in order to work correctly and reliably as a compiler. Hopefully the clang developers will understand this for the future also.
+1 I'd like (expect even) a standalone distribution to 'just work' on Windows (and other IDEs). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
The configuration with the built-in clang++ in C++11 mode should just be disabled; the default libstdc++ on Travis is 4.6 and is too broken for any serious C++11 work.
Looking at the current log, it seems that it can be fixed by disabling <condition_variable> for libstdc++ 4.6 on Clang, as this is the only test that doesn't compile.
participants (5)
-
Edward Diener -
John Maddock -
paul -
Paul A. Bristow -
Peter Dimov