Should the clang, c++11 and libstdc++ configuration supported?
Hi, clang compiler is not delivered with a C++11 standard library. When compiling on c++11 mode, some boost libraries (in particular, Boost.Thread, Boost.SmartPtr, Boost.Test) are expecting to have a C++11 standard library. This mean that the user needs to install the latest version of libc++. Could we state clearly in the release notes if the combination clang+ -std=c++11 + libstdc++ is not supported. Otherwise these libraries should update their code so that the user can use this combination. Best, Vicente
On 17 November 2012 12:04, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
clang compiler is not delivered with a C++11 standard library. When compiling on c++11 mode, some boost libraries (in particular, Boost.Thread, Boost.SmartPtr, Boost.Test) are expecting to have a C++11 standard library. This mean that the user needs to install the latest version of libc++.
Are you sure about that? I just tried SmartPtr and almost all tests passed. The only problem was that a couple of tests used initializer_lists
Could we state clearly in the release notes if the combination clang+ -std=c++11 + libstdc++ is not supported. Otherwise these libraries should update their code so that the user can use this combination.
Well, some libraries do support that configuration so there's no blanket level of support. And that's pretty much always the case with boost. Individual libraries should list what they support. I'm not going to spend time keeping this information up to date. If someone else wants to volunteer then they're welcome to. 'Official' clang support is actually pretty limited - only clang 2.8 on linux is listed as a primary test compiler. This is because most of the testers aren't using stable releases, and we decided some time ago to only list stable releases as primary. Although I probably should list the library used in the tests. I mainly haven't because writing the list of compilers is tedious enough already. It should really be automated.
On Sat, Nov 17, 2012 at 7:43 AM, Daniel James <dnljms@gmail.com> wrote:
On 17 November 2012 12:04, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
clang compiler is not delivered with a C++11 standard library. When compiling on c++11 mode, some boost libraries (in particular, Boost.Thread, Boost.SmartPtr, Boost.Test) are expecting to have a C++11 standard library. This mean that the user needs to install the latest version of libc++.
Are you sure about that?
Like Daniel, I'm not sure that "clang compiler is not delivered with a C++11 standard library." is correct. Doesn't the way Clang gets "delivered" depend on the platform and distribution involved? I've only use Clang a few times, but IIRC all the distributions I've used supplied a C++ standard library as part of the package. --Beman
On 17 November 2012 13:59, Beman Dawes <bdawes@acm.org> wrote:
On Sat, Nov 17, 2012 at 7:43 AM, Daniel James <dnljms@gmail.com> wrote:
On 17 November 2012 12:04, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
clang compiler is not delivered with a C++11 standard library. When compiling on c++11 mode, some boost libraries (in particular, Boost.Thread, Boost.SmartPtr, Boost.Test) are expecting to have a C++11 standard library. This mean that the user needs to install the latest version of libc++.
Are you sure about that?
Like Daniel, I'm not sure that "clang compiler is not delivered with a C++11 standard library." is correct. Doesn't the way Clang gets "delivered" depend on the platform and distribution involved? I've only use Clang a few times, but IIRC all the distributions I've used supplied a C++ standard library as part of the package.
That wasn't what I meant (it'd have been smarter if I did). Like intel, clang is different everywhere. It often uses the native gcc standard library, which is occasionally an old one with no C++11 support. Because apple stopped updating gcc after 4.2, the default version of libstdc++ doesn't have C++11 support. I'm sure it's possible to use a more recent version, but I've never tried. I'm really not sure if this is a real problem. The only 'real' case I've seen was a bug report from someone using unordered in C++11 mode with a C++03 std::allocator. But I think things like move support were introduced earlier than allocator support pretty much everywhere.
clang compiler is not delivered with a C++11 standard library. When compiling on c++11 mode, some boost libraries (in particular, Boost.Thread, Boost.SmartPtr, Boost.Test) are expecting to have a C++11 standard library. This mean that the user needs to install the latest version of libc++.
Are you sure about that?
Like Daniel, I'm not sure that "clang compiler is not delivered with a C++11 standard library." is correct. Doesn't the way Clang gets "delivered" depend on the platform and distribution involved? I've only use Clang a few times, but IIRC all the distributions I've used supplied a C++ standard library as part of the package.
That wasn't what I meant (it'd have been smarter if I did). Like intel, clang is different everywhere. It often uses the native gcc standard library, which is occasionally an old one with no C++11 support. Because apple stopped updating gcc after 4.2, the default version of libstdc++ doesn't have C++11 support. I'm sure it's possible to use a more recent version, but I've never tried.
in my experience clang++ does not play well with libstdc++ in c++11 mode ... at least std::thread is completely broken ... this is a known issue and the bug report already half a year old ... without any activity ... but i suppose the reason is simply that for the clang sponsors libstdc++/c++11 compatibility is not relevant ... tim
Le 17/11/12 14:59, Beman Dawes a écrit :
On Sat, Nov 17, 2012 at 7:43 AM, Daniel James <dnljms@gmail.com> wrote:
On 17 November 2012 12:04, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
clang compiler is not delivered with a C++11 standard library. When compiling on c++11 mode, some boost libraries (in particular, Boost.Thread, Boost.SmartPtr, Boost.Test) are expecting to have a C++11 standard library. This mean that the user needs to install the latest version of libc++. Are you sure about that? Like Daniel, I'm not sure that "clang compiler is not delivered with a C++11 standard library." is correct. Doesn't the way Clang gets "delivered" depend on the platform and distribution involved? I've only use Clang a few times, but IIRC all the distributions I've used supplied a C++ standard library as part of the package.
I mean a C++11 standard library :) Vicente
On 17 November 2012 12:43, Daniel James <dnljms@gmail.com> wrote:
On 17 November 2012 12:04, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
clang compiler is not delivered with a C++11 standard library. When compiling on c++11 mode, some boost libraries (in particular, Boost.Thread, Boost.SmartPtr, Boost.Test) are expecting to have a C++11 standard library. This mean that the user needs to install the latest version of libc++.
Are you sure about that? I just tried SmartPtr and almost all tests passed. The only problem was that a couple of tests used initializer_lists
Oops, I used the wrong command when I ran the tests, I meant to delete that paragraph.
Daniel James wrote:
On 17 November 2012 12:43, Daniel James <dnljms@gmail.com> wrote:
On 17 November 2012 12:04, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
clang compiler is not delivered with a C++11 standard library. When compiling on c++11 mode, some boost libraries (in particular, Boost.Thread, Boost.SmartPtr, Boost.Test) are expecting to have a C++11 standard library. This mean that the user needs to install the latest version of libc++.
Are you sure about that? I just tried SmartPtr and almost all tests passed. The only problem was that a couple of tests used initializer_lists
Oops, I used the wrong command when I ran the tests, I meant to delete that paragraph.
What parts of SmartPtr don't work with clang/libstdc++?
On 17 November 2012 14:31, Peter Dimov <lists@pdimov.com> wrote:
What parts of SmartPtr don't work with clang/libstdc++?
There are calls to std::forward in boost/smart_ptr/make_shared_array.hpp, and boost/smart_ptr/allocate_shared_array.hpp that check for compiler support but not library support. I don't know if there's an appropriate config macro. This is only an issue with older versions of libstdc++ in C++11 mode, so I don't think it's a common problem. I only came across it in Boost.Test because I was trying to recreate an error people were seeing. For normal development, I'd never do it.
Daniel James wrote:
On 17 November 2012 14:31, Peter Dimov <lists@pdimov.com> wrote:
What parts of SmartPtr don't work with clang/libstdc++?
There are calls to std::forward in boost/smart_ptr/make_shared_array.hpp, and boost/smart_ptr/allocate_shared_array.hpp that check for compiler support but not library support. I don't know if there's an appropriate config macro.
That's fixable. There's detail::sp_forward for that very purpose.
This is only an issue with older versions of libstdc++ in C++11 mode, so I don't think it's a common problem.
It was a common problem in the past when g++ itself suffered from it, which is why there are so few errors in SmartPtr. :-) But, realistically, if there's no tester for that configuration, we'll lose support for it when changes get made.
Le 17/11/12 15:52, Daniel James a écrit :
On 17 November 2012 14:31, Peter Dimov <lists@pdimov.com> wrote:
What parts of SmartPtr don't work with clang/libstdc++? There are calls to std::forward in boost/smart_ptr/make_shared_array.hpp, and boost/smart_ptr/allocate_shared_array.hpp that check for compiler support but not library support. I don't know if there's an appropriate config macro. I confirm. This is only an issue with older versions of libstdc++ in C++11 mode, so I don't think it's a common problem. I only came across it in Boost.Test because I was trying to recreate an error people were seeing. For normal development, I'd never do it.
So IIUC, the config clang + -std=c++0x/c++11 + gcc non c++11 supporting library is not a usual case, and so should not be supported. Every time I've installed clang on MacOs it uses a standard library non-supporting c++11. I though that was a know issue. Best, Vicente
On 17 November 2012 15:25, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 17/11/12 15:52, Daniel James a écrit :
This is only an issue with older versions of libstdc++ in C++11 mode, so I don't think it's a common problem. I only came across it in Boost.Test because I was trying to recreate an error people were seeing. For normal development, I'd never do it.
So IIUC, the config clang + -std=c++0x/c++11 + gcc non c++11 supporting library is not a usual case, and so should not be supported.
No, I just don't think it's common, so it isn't essential. But it's certainly nice to support it - I do. I don't have any real data on how common it is, and the same issue might pop up elsewhere, so it's hard to tell just how important it is, or isn't.
Every time I've installed clang on MacOs it uses a standard library non-supporting c++11. I though that was a know issue.
Yes, I mentioned that in another mail. Apple doesn't support gcc versions after 4.2, so the default libstdc++ is an old one. I just imagine that anyone who wants to use clang for c++11 development on a mac with Snow Leopard or later will install libc++, or just use a recent g++.
Le 17/11/12 16:36, Daniel James a écrit :
On 17 November 2012 15:25, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 17/11/12 15:52, Daniel James a écrit :
This is only an issue with older versions of libstdc++ in C++11 mode, so I don't think it's a common problem. I only came across it in Boost.Test because I was trying to recreate an error people were seeing. For normal development, I'd never do it.
So IIUC, the config clang + -std=c++0x/c++11 + gcc non c++11 supporting library is not a usual case, and so should not be supported. No, I just don't think it's common, so it isn't essential. But it's certainly nice to support it - I do. I don't have any real data on how common it is, and the same issue might pop up elsewhere, so it's hard to tell just how important it is, or isn't. Boost.Thread can not support this combination until Boost.SmartPtr and Boost.Test fixes them. I has the impression that Peter has the intention to fix it, but don't Gennadiy. If Boost.test don't fixes this combination a lot of libraries will be concerned, at least for what concerns their own tests.
Best, Vicente
Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
Boost.Test fixes them. I has the impression that Peter has the intention to fix it, but don't Gennadiy. If Boost.test don't fixes this
I must have missed where you mentioned it. What exactly is broken? Gennadiy
Le 17/11/12 19:32, Gennadiy Rozental a écrit :
Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
Boost.Test fixes them. I has the impression that Peter has the intention to fix it, but don't Gennadiy. If Boost.test don't fixes this I must have missed where you mentioned it. What exactly is broken?
Hi, I've created a ticket https://svn.boost.org/trac/boost/ticket/7708 that gives you all the errors found while running the Boost.Test regression tests. Maybe there are errors that are not related to the subject, I have not filtered them. Best, Vicente
On Sat, Nov 17, 2012 at 10:36 AM, Daniel James <dnljms@gmail.com> wrote:
I just imagine that anyone who wants to use clang for c++11 development on a mac with Snow Leopard or later will install libc++, or just use a recent g++.
If you want to use libc++ and still support OS X < 10.7 or iOS < 5, you'll have to bake your own compiler toolchain into Xcode, or do everything from the command line (probably also involves some baking). You may not even get it to work for an iOS app at all, if it requires a dylib (at least, it won't be possible to get it in the app store). C++11 with libstdc++ is fairly common because it is the only way to maintain support for these (modestly) older OS versions. People still want the new language features, then use boost as a fallback for things like thread, mutex, etc. By the way, the new Android NDK (r8c) supports clang 3.1. It relies on libstdc++, but no libc++ as far as know.
On 21 November 2012 02:28, Rich E <reakinator@gmail.com> wrote:
If you want to use libc++ and still support OS X < 10.7 or iOS < 5, you'll have to bake your own compiler toolchain into Xcode, or do everything from the command line (probably also involves some baking). You may not even get it to work for an iOS app at all, if it requires a dylib (at least, it won't be possible to get it in the app store).
C++11 with libstdc++ is fairly common because it is the only way to maintain support for these (modestly) older OS versions. People still want the new language features, then use boost as a fallback for things like thread, mutex, etc.
Thanks, that's good to know. So this is something we should be concerned about.
By the way, the new Android NDK (r8c) supports clang 3.1. It relies on libstdc++, but no libc++ as far as know.
That makes sense, libc++ support for linux isn't all there yet. It looks like they're using libstdc++ from gcc 4.4. So it's less of a problem there. It's a pity we don't have any testers for these common setups. There seems to be a disconnect between the way we develop and the way boost is used. Maybe there should at least be a wiki page somewhere describing the default setup for various platforms. The boost wiki isn't really appropriate, because access is too limited. Maybe we could set something up on github.
Vicente J. Botet Escriba wrote:
So IIUC, the config clang + -std=c++0x/c++11 + gcc non c++11 supporting library is not a usual case, and so should not be supported.
Every time I've installed clang on MacOs it uses a standard library non-supporting c++11. I though that was a know issue.
If you report specific errors in SmartPtr, or submit a ticket, I will try to fix them if it's not much of a hassle. (If you don't, I won't.)
Le 17/11/12 17:17, Peter Dimov a écrit :
Vicente J. Botet Escriba wrote:
So IIUC, the config clang + -std=c++0x/c++11 + gcc non c++11 supporting library is not a usual case, and so should not be supported.
Every time I've installed clang on MacOs it uses a standard library non-supporting c++11. I though that was a know issue.
If you report specific errors in SmartPtr, or submit a ticket, I will try to fix them if it's not much of a hassle. (If you don't, I won't.)
Hi, here it is https://svn.boost.org/trac/boost/ticket/7707. Best, Vicente
On 17/11/12 15:52, Daniel James wrote:
On 17 November 2012 14:31, Peter Dimov <lists@pdimov.com> wrote:
What parts of SmartPtr don't work with clang/libstdc++?
There are calls to std::forward in boost/smart_ptr/make_shared_array.hpp, and boost/smart_ptr/allocate_shared_array.hpp that check for compiler support but not library support. I don't know if there's an appropriate config macro.
Personally I recommend avoiding std::forward, at least for code that needs to be compatible with other than the best and latest compilers. It adds an unnecessary dependency on a library component, is not very useful (static_cast<T&&>(t) looks essentially the same as std::forward<T>(t)), and it adds an uncessary function call, which means bloat and debugging annoyances.
This is only an issue with older versions of libstdc++ in C++11 mode, so I don't think it's a common problem. I only came across it in Boost.Test because I was trying to recreate an error people were seeing. For normal development, I'd never do it.
It probably also affects other compilers that have C++11 but no C++11 standard library, like xlC.
On 17/11/12 13:04, Vicente J. Botet Escriba wrote:
When compiling on c++11 mode, some boost libraries (in particular, Boost.Thread, Boost.SmartPtr, Boost.Test) are expecting to have a C++11 standard library.
That expectation is broken. If the code is written so that it can work with either a C++03 or C++11 version of the library, it should select the C++11 version only if the standard library has the required components, not if the core language has the features the components uses.
participants (8)
-
Beman Dawes -
Daniel James -
Gennadiy Rozental -
Mathias Gaunard -
Peter Dimov -
Rich E -
Tim Blechmann -
Vicente J. Botet Escriba