Boost C++ Libraries: Ticket #7671: Error including boost/thread.hpp header on iOS

viboes — Fri, 09 Nov 2012 14:15:07 GMT

Could you show the exact command and the compiler error and the source file?

viboes — Fri, 09 Nov 2012 14:20:14 GMT

I guess that you should link with libc++ which is C++11 aware.

Fri, 09 Nov 2012 15:47:29 GMT

I could not access the specific command the Xcode IDE issues (I will try it with xcodebuild on the command line later), but the error message in the header boost/chrono/duration.hpp says "Non-constexpr function 'max' cannot be used in constant expression".

I just noticed that the issue goes away if I remove BOOST_CHRONO_LIB_CONSTEXPR in lines 353, 361 and 369 in the file boost/chrono/duration.hpp and the project compiles fine.

Fri, 09 Nov 2012 15:54:38 GMT

Replying to viboes: The project uses C++11 and the compiler supports the constexpr statement. The issue seems to be that the boost-header assumes that std::numeric_limits<float>::max is a compile-time constant which is not the case on the given platform.

viboes — Fri, 09 Nov 2012 17:06:35 GMT

Replying to Wolfram Schroers <Dr.Schroers@…>:

Replying to viboes: The project uses C++11 and the compiler supports the constexpr statement. The issue seems to be that the boost-header assumes that std::numeric_limits<float>::max is a compile-time constant which is not the case on the given platform.

As said before you need to use a std lib compatible with C++11. libc++ is free and works well with clang.

Sat, 10 Nov 2012 19:25:19 GMT

Replying to viboes: [...]

As said before you need to use a std lib compatible with C++11. libc++ is free and works well with clang.

In the default answer of http://stackoverflow.com/questions/12865226/in-xcode-4-5-what-is-compiler-default-for-c-standard-library-and-c-lan?rq=1 this post there is specific code to test for stdlib++ vs. lib++. The output for me is:

Using libc++
Language mode = gnu++11

I am not sure how to proceed in this case, because it looks like I am already using libc++.

viboes — Sat, 10 Nov 2012 20:49:01 GMT

Replying to Wolfram Schroers <Dr.Schroers@…>:

Replying to viboes: [...]

As said before you need to use a std lib compatible with C++11. libc++ is free and works well with clang.

In the default answer of http://stackoverflow.com/questions/12865226/in-xcode-4-5-what-is-compiler-default-for-c-standard-library-and-c-lan?rq=1 this post there is specific code to test for stdlib++ vs. lib++. The output for me is:
Using libc++
Language mode = gnu++11
I am not sure how to proceed in this case, because it looks like I am already using libc++.

Hrrr. I'm using MacOS 10.7.5 and when I compile for C++11 and use libc++ I don't get any error.

Which version of libc++ are you using? Which version of the compiler?

viboes — Sat, 10 Nov 2012 23:01:29 GMT

The source of libc++ <limits< contains the following

template <class _Tp>
class _LIBCPP_VISIBLE numeric_limits
    : private __libcpp_numeric_limits<typename remove_cv<_Tp>::type>
{
    typedef __libcpp_numeric_limits<typename remove_cv<_Tp>::type> __base;
    typedef typename __base::type type;
public:
    static _LIBCPP_CONSTEXPR const bool is_specialized = __base::is_specialized;
    _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type min() _NOEXCEPT {return __base::min();}
    _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() _NOEXCEPT {return __base::max();}

with specializations for float, double and long double

template <>
class __libcpp_numeric_limits<float, true>
{
protected:
...
    _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type min() _NOEXCEPT {return __FLT_MIN__;}
    _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() _NOEXCEPT {return __FLT_MAX__;}

I don't see why then the error occurs. Please could you verify the code inside <limits> on your configuration?

Sun, 11 Nov 2012 07:13:56 GMT

Replying to viboes:

In my case the file contains:

template <class _Tp>
class _LIBCPP_VISIBLE numeric_limits
    : private __libcpp_numeric_limits<typename remove_cv<_Tp>::type>
{
    typedef __libcpp_numeric_limits<typename remove_cv<_Tp>::type> __base;
    typedef typename __base::type type;
public:
    static const bool is_specialized = __base::is_specialized;
    _LIBCPP_INLINE_VISIBILITY static type min() _NOEXCEPT {return __base::min();}
    _LIBCPP_INLINE_VISIBILITY static type max() _NOEXCEPT {return __base::max();}
    _LIBCPP_INLINE_VISIBILITY static type lowest() _NOEXCEPT {return __base::lowest();}

I have created a minimal Xcode project file that shows the error when compiling and attached the file to this report. The version numbers are stated in the original report. Hope that helps ...

attachment set

Sun, 11 Nov 2012 07:14:43 GMT

attachment → BoostTest.tgz

Sample project that demonstrates the error

rkb — Tue, 13 Nov 2012 01:23:00 GMT

Hello -- came across this thread during search for issue.

From my xcode experiment to build basic thread program, ran into same issue.

On my end - I switched to C++ Standard Library libstdc++ and was able to compile my program. Earlier errors were the same as above.

Tue, 13 Nov 2012 09:45:02 GMT

Replying to rkb: [...]

On my end - I switched to C++ Standard Library libstdc++ and was able to compile my program. Earlier errors were the same as above.

I have just explicitly added libstdc++.dylib to the "Link Binary With Libraries" section of the "Build Phases" tab. The result is unchanged, however. As far as I can see, the .dylib library does not come with a separate header file and the issue is in the header limits.

Could you be a little more explicit in describing how you switched the library?

rkb — Tue, 13 Nov 2012 12:46:09 GMT

Hello. My apologies. To detail a bit more:

Under project build settings in xcode, try searching for "lib" via the search field. Under Apple LLVM compiler 4.1, a field called C++ Standard Library appears. Just click this to toggle to libstdc++ (GNU C++ standard library).

It was after this change that I was able to successfully compile. Please let me know if this is helpful.

tuhertz — Tue, 13 Nov 2012 14:23:45 GMT

libc++ in Xcode is outdated , so constexpr keyword missing in limits header. It should work fine if you change C++ language dialect to C++98 or GNU++98. If you want to compile Boost with C++11 dialect, you need to get latest headers from libc++ trunk.

Tue, 13 Nov 2012 15:35:49 GMT

Changing the libc++ to libstdc++ in the "C++ Standard Library" row in the "Build Settings" yields 50+ linker errors. This does not appear to work.

I also do not feel comfortable installing custom headers for what feels like a basic system library. There may be potential side effects, including the danger that some modification under the hood could endanger app store approval or something ...

The only practical solution I have found so far is to edit the boost header <boost/thread.hpp> and remove the BOOST_CHRONO_LIB_CONSTEXPR keyword.

tuhertz — Tue, 13 Nov 2012 16:42:49 GMT

If you don't change C++ Language Dialect in Build Setting, you will get errors no matter which library you choose. Because Boost knows your compiler supports C+11 constexpr, but both libc++ and libstdc++ don't implement it in limits header. Changing language dialect to C++98 is easiest fix if you don't have to build Boost with C++11.

I think building with custom limits header won't make any trouble, because limits is header only library and all classes are empty classes. All members are static or inline methods, so it will just replace with constants in Boost library in compilation time. You don't need to replacing system header, just adding it's location to Header Search Path in build settings, it takes precedence over system header.

libc++ has been updated in Xcode 4.6 developer preview and i confirm limit header is updated also, so this problem will be gone in next Xcode release.

attachment set

Tue, 13 Nov 2012 18:17:28 GMT

attachment → libcpp_c11_numeric_limits.patch

Set BOOST_NO_CXX11_NUMERIC_LIMITS for Xcode 4.5 to fix compilation error.

owner, component changed; cc set

viboes — Sat, 17 Nov 2012 08:47:51 GMT

cc viboes added
owner changed from Anthony Williams to John Maddock
component thread → config

Wed, 28 Nov 2012 14:49:07 GMT

Thanks for your responses. In my situation switching to Xcode 4.6 is the best choice at the moment. The alternative patch file is also a good alternative, but I'll go with switching to the developer preview for now.

me@… — Mon, 17 Dec 2012 17:18:53 GMT

You can also add #define BOOST_THREAD_DONT_USE_CHRONO before including the Boost headers for this error to go away.

owner, status, component changed

viboes — Wed, 16 Jan 2013 22:50:43 GMT

owner changed from John Maddock to viboes
status new → assigned
component config → thread

[82391] Should have fixed this issue.

status, milestone changed; resolution set

viboes — Thu, 17 Jan 2013 18:17:41 GMT

status assigned → closed
resolution → fixed
milestone To Be Determined → Boost 1.53.0