[1.53.0] Beta release candidates 2 now available for testing
Updated release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 579b680bf55f53cd6d50adc391cb6c23 *boost_1_53_0_beta1_rc2.tar.gz 02098bb6da0e9c10712ae63c16e6aeea *boost_1_53_0_beta1_rc2.tar.bz2 998e2616a66c50e5693f563afb899002 *boost_1_53_0_beta1_rc2.zip e4fde6a869a3e21f8751ba8b7fd471a8 *boost_1_53_0_beta1_rc2.7z There were three changes between rc1 and rc2: * Fixes for compilation errors in Boost.Serialization * Documentation updates for Boost.SmartPtr * Updates to Boost.Threads Thanks, --The release managers
On Fri, Jan 4, 2013 at 8:25 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
VC11 ...failed updating 5 targets... : C:\VC\boost_1_53_0_beta1>b2 --build-type=complete Building the Boost C++ Libraries. Performing configuration checks - 32-bit : yes - x86 : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - gcc visibility : no - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. warning: No python installation configured and autoconfiguration note: failed. See http://www.boost.org/libs/python/doc/building.html note: for configuration instructions or pass --without-python to note: suppress this message and silently skip all Boost.Python targets Component configuration: - atomic : building - chrono : building - context : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building ...patience... ...patience... ...patience... ...patience... ...found 9372 targets... ...updating 9 targets... msvc.link.dll bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.dll Creating library bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.lib and object bin.v2\libs\context\build\msvc-11.0\ debug\threading-multi\boost_context-vc110-mt-gd-1_53.exp make_i386_ms_pe_masm.obj : error LNK2019: unresolved external symbol __exit referenced in function _make_fcontext LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12 bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.dll : fatal error LNK1120: 2 unresolved externals call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x86 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X86 /subsystem:console /out:"bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt- gd-1_53.dll" /IMPLIB:"bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.lib" @"bin.v2\libs\context\build\msvc-11.0\deb ug\threading-multi\boost_context-vc110-mt-gd-1_53.dll.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% ...failed msvc.link.dll bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.dll bin.v2\libs\context\build\msvc-11.0\debug\t hreading-multi\boost_context-vc110-mt-gd-1_53.lib bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.pdb... ...removing bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.lib ...removing bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.pdb ...skipped <pstage\lib>boost_context-vc110-mt-gd-1_53.dll for lack of <pbin.v2\libs\context\build\msvc-11.0\debug\threading-multi>boost_context-vc110-mt-gd-1_53 .dll... ...skipped <pstage\lib>boost_context-vc110-mt-gd-1_53.lib for lack of <pbin.v2\libs\context\build\msvc-11.0\debug\threading-multi>boost_context-vc110-mt-gd-1_53 .lib... msvc.link.dll bin.v2\libs\context\build\msvc-11.0\release\threading-multi\boost_context-vc110-mt-1_53.dll Creating library bin.v2\libs\context\build\msvc-11.0\release\threading-multi\boost_context-vc110-mt-1_53.lib and object bin.v2\libs\context\build\msvc-11.0\r elease\threading-multi\boost_context-vc110-mt-1_53.exp make_i386_ms_pe_masm.obj : error LNK2019: unresolved external symbol __exit referenced in function _make_fcontext LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12 bin.v2\libs\context\build\msvc-11.0\release\threading-multi\boost_context-vc110-mt-1_53.dll : fatal error LNK1120: 2 unresolved externals call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x86 >nul link /NOLOGO /INCREMENTAL:NO /DLL /MACHINE:X86 /subsystem:console /out:"bin.v2\libs\context\build\msvc-11.0\release\threading-multi\boost_context-vc110-mt-1_53. dll" /IMPLIB:"bin.v2\libs\context\build\msvc-11.0\release\threading-multi\boost_context-vc110-mt-1_53.lib" @"bin.v2\libs\context\build\msvc-11.0\release\thre ading-multi\boost_context-vc110-mt-1_53.dll.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% ...failed msvc.link.dll bin.v2\libs\context\build\msvc-11.0\release\threading-multi\boost_context-vc110-mt-1_53.dll bin.v2\libs\context\build\msvc-11.0\release\ threading-multi\boost_context-vc110-mt-1_53.lib... ...removing bin.v2\libs\context\build\msvc-11.0\release\threading-multi\boost_context-vc110-mt-1_53.lib ...skipped <pstage\lib>boost_context-vc110-mt-1_53.dll for lack of <pbin.v2\libs\context\build\msvc-11.0\release\threading-multi>boost_context-vc110-mt-1_53.dll ... ...skipped <pstage\lib>boost_context-vc110-mt-1_53.lib for lack of <pbin.v2\libs\context\build\msvc-11.0\release\threading-multi>boost_context-vc110-mt-1_53.lib ... ...failed updating 5 targets... ...skipped 4 targets...
On 1/4/2013 12:41 PM, Olaf van der Spek wrote:
On Fri, Jan 4, 2013 at 8:25 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
VC11 ...failed updating 5 targets... :
C:\VC\boost_1_53_0_beta1>b2 --build-type=complete
Building the Boost C++ Libraries. <snip> ... ...failed updating 5 targets... ...skipped 4 targets...
I also get errors building Boost.Context, and Boost.Python too. Log attached[*]. Python 2.7 is installed in the default location. Should it build without errors? I confess I haven't tried this before. :-P [*] err.log (103 KB) hosted on YouSendIt: http://www.yousendit.com/download/UW13ck85UnE1bmpvS3NUQw -- Eric Niebler BoostPro Computing http://www.boostpro.com
Can anybody comment on this? On 1/4/2013 4:41 PM, Eric Niebler wrote:
On 1/4/2013 12:41 PM, Olaf van der Spek wrote:
On Fri, Jan 4, 2013 at 8:25 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
VC11 ...failed updating 5 targets... :
C:\VC\boost_1_53_0_beta1>b2 --build-type=complete
Building the Boost C++ Libraries. <snip> ... ...failed updating 5 targets... ...skipped 4 targets...
I also get errors building Boost.Context, and Boost.Python too. Log attached[*]. Python 2.7 is installed in the default location. Should it build without errors? I confess I haven't tried this before. :-P
[*] err.log (103 KB) hosted on YouSendIt: http://www.yousendit.com/download/UW13ck85UnE1bmpvS3NUQw
-- Eric Niebler BoostPro Computing http://www.boostpro.com
2013/1/6 Eric Niebler <eric@boostpro.com>
Can anybody comment on this?
msvc.link.dll bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.dll Creating library bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.lib and object bin.v2\libs\context\build\msvc-11.0\ debug\threading-multi\boost_context-vc110-mt-gd-1_53.exp make_i386_ms_pe_masm.obj : error LNK2019: unresolved external symbol __exit referenced in function _make_fcontext LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12 I assume the error report refers to target-os=Windows (32bit) As the error describes the linker can not find symbol __exit (note two underscores!). the assembler code in make_i386_ms_pe_masm.asm calls _exit (_exit() from c-library) - I don't know why the assembler (is it MASM?, which version?) adds a leading underscore to _exit (and _DllMainCRTStartup too). If take a I look at the regression tests in trunk I see that the test pass ( teeks99-1a-win7-32on64).<http://www.boost.org/development/tests/trunk/teeks99-1a-win7-32on64.html> Even __DllMainCRTStartup should be _DllMainCRTStartup. maybe some additional compiler flags are responsive for this behaviour?
On Fri, Jan 4, 2013 at 2:41 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Fri, Jan 4, 2013 at 8:25 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
VC11 ...failed updating 5 targets... :
C:\VC\boost_1_53_0_beta1>b2 --build-type=complete
msvc.link.dll bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.dll Creating library
bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.lib and object bin.v2\libs\context\build\msvc-11.0\ debug\threading-multi\boost_context-vc110-mt-gd-1_53.exp make_i386_ms_pe_masm.obj : error LNK2019: unresolved external symbol __exit referenced in function _make_fcontext LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12
bin.v2\libs\context\build\msvc-11.0\debug\threading-multi\boost_context-vc110-mt-gd-1_53.dll : fatal error LNK1120: 2 unresolved externals <snip>
I'm showing the same errors for all visual studio versions I run (VC8, VC9, VC10, and VC11) with 32&64 bit complies. Tom
Is ticket 7695 in this release (proper vc11 features). The bug is closed, but has no associated milestone. It'd be nice to have since it's done. Charles Wilson Senior Software Development Engineer Dell | Enterprise Solutions Group
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Marshall Clow Sent: Friday, January 04, 2013 1:25 PM To: Boost Developers List; boost-users@lists.boost.org Subject: [boost] [1.53.0] Beta release candidates 2 now available for testing
Updated release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
The files (and associated md5s) are: 579b680bf55f53cd6d50adc391cb6c23 *boost_1_53_0_beta1_rc2.tar.gz 02098bb6da0e9c10712ae63c16e6aeea *boost_1_53_0_beta1_rc2.tar.bz2 998e2616a66c50e5693f563afb899002 *boost_1_53_0_beta1_rc2.zip e4fde6a869a3e21f8751ba8b7fd471a8 *boost_1_53_0_beta1_rc2.7z
There were three changes between rc1 and rc2: * Fixes for compilation errors in Boost.Serialization * Documentation updates for Boost.SmartPtr * Updates to Boost.Threads
Thanks,
--The release managers
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Jan 4, 2013, at 1:05 PM, Charles_J_Wilson@Dell.com wrote:
Is ticket 7695 in this release (proper vc11 features). The bug is closed, but has no associated milestone.
It'd be nice to have since it's done.
Yes, it is. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Jan 4, 2013, at 11:25 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Updated release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I built the RC on Mac OS X with both clang and gcc w/o errors. However, when I built using clang and libc++ in C++11 mode, I found two problems: ./b2 toolset=clang cxxflags="-std=c++11 -stdlib=libc++ -Wno-unused-variable" linkflags="-stdlib=libc++" Issue #1:
clang-darwin.compile.c++ bin.v2/libs/chrono/build/clang-darwin-11/release/threading-multi/chrono.o In file included from libs/chrono/src/chrono.cpp:14: In file included from ./boost/chrono/detail/inlined/chrono.hpp:13: In file included from ./boost/chrono/chrono.hpp:11: ./boost/chrono/duration.hpp:353:49: error: constexpr function never produces a constant expression static BOOST_CHRONO_LIB_CONSTEXPR float lowest() BOOST_CHRONO_LIB_NOEXCEPT_OR_THROW ^ ./boost/chrono/duration.hpp:355:21: note: non-constexpr function 'max' cannot be used in a constant expression return -(std::numeric_limits<float>::max) (); ^ /usr/bin/../lib/c++/v1/limits:443:43: note: declared here _LIBCPP_INLINE_VISIBILITY static type max() _NOEXCEPT {return __base::max();} ^
This is a bug in libc++; std::numeric_limits<>::max() is not marked as constexpr. This has been fixed in the libc++ trunk, and should appear in the next clang/libc++ release. Issue #2:
clang-darwin.compile.c++ bin.v2/libs/filesystem/build/clang-darwin-11/release/threading-multi/path.o In file included from libs/filesystem/src/path.cpp:39: In file included from ./boost/filesystem/detail/utf8_codecvt_facet.hpp:18: ./boost/detail/utf8_codecvt_facet.hpp:171:17: warning: 'boost::filesystem::detail::utf8_codecvt_facet::do_length' hides overloaded virtual function [-Woverloaded-virtual] virtual int do_length( ^ /usr/bin/../lib/c++/v1/__locale:920:17: note: hidden overloaded virtual function 'std::__1::codecvt<wchar_t, char, __mbstate_t>::do_length' declared here virtual int do_length(state_type&, const extern_type* __frm, const extern_type* __end, size_t __mx) const; ^
This is my fault - there's a change that I failed to merge. I will fix this before the release. -- Marshall
Le 05/01/13 18:37, Marshall Clow a écrit :
On Jan 4, 2013, at 11:25 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Updated release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. I built the RC on Mac OS X with both clang and gcc w/o errors. However, when I built using clang and libc++ in C++11 mode, I found two problems:
./b2 toolset=clang cxxflags="-std=c++11 -stdlib=libc++ -Wno-unused-variable" linkflags="-stdlib=libc++"
Issue #1:
clang-darwin.compile.c++ bin.v2/libs/chrono/build/clang-darwin-11/release/threading-multi/chrono.o In file included from libs/chrono/src/chrono.cpp:14: In file included from ./boost/chrono/detail/inlined/chrono.hpp:13: In file included from ./boost/chrono/chrono.hpp:11: ./boost/chrono/duration.hpp:353:49: error: constexpr function never produces a constant expression static BOOST_CHRONO_LIB_CONSTEXPR float lowest() BOOST_CHRONO_LIB_NOEXCEPT_OR_THROW ^ ./boost/chrono/duration.hpp:355:21: note: non-constexpr function 'max' cannot be used in a constant expression return -(std::numeric_limits<float>::max) (); ^ /usr/bin/../lib/c++/v1/limits:443:43: note: declared here _LIBCPP_INLINE_VISIBILITY static type max() _NOEXCEPT {return __base::max();} ^ This is a bug in libc++; std::numeric_limits<>::max() is not marked as constexpr. This has been fixed in the libc++ trunk, and should appear in the next clang/libc++ release. Hi, I defined BOOST_CHRONO_LIB_CONSTEXPR as follows to avoid this problem.
#if defined( BOOST_NO_CXX11_NUMERIC_LIMITS ) #define BOOST_CHRONO_LIB_CONSTEXPR #else #define BOOST_CHRONO_LIB_CONSTEXPR BOOST_CONSTEXPR #endif Shouldn't BOOST_NO_CXX11_NUMERIC_LIMITS be defined as it doesn't providesa C++11 implementation, or should Boost.Chrono take in account the missing feature of libc++ individually? BTW, which version of libc++ are you using? Best, Vicente
On Jan 5, 2013, at 2:45 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 05/01/13 18:37, Marshall Clow a écrit :
On Jan 4, 2013, at 11:25 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Updated release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. I built the RC on Mac OS X with both clang and gcc w/o errors. However, when I built using clang and libc++ in C++11 mode, I found two problems:
./b2 toolset=clang cxxflags="-std=c++11 -stdlib=libc++ -Wno-unused-variable" linkflags="-stdlib=libc++"
Issue #1:
clang-darwin.compile.c++ bin.v2/libs/chrono/build/clang-darwin-11/release/threading-multi/chrono.o In file included from libs/chrono/src/chrono.cpp:14: In file included from ./boost/chrono/detail/inlined/chrono.hpp:13: In file included from ./boost/chrono/chrono.hpp:11: ./boost/chrono/duration.hpp:353:49: error: constexpr function never produces a constant expression static BOOST_CHRONO_LIB_CONSTEXPR float lowest() BOOST_CHRONO_LIB_NOEXCEPT_OR_THROW ^ ./boost/chrono/duration.hpp:355:21: note: non-constexpr function 'max' cannot be used in a constant expression return -(std::numeric_limits<float>::max) (); ^ /usr/bin/../lib/c++/v1/limits:443:43: note: declared here _LIBCPP_INLINE_VISIBILITY static type max() _NOEXCEPT {return __base::max();} ^ This is a bug in libc++; std::numeric_limits<>::max() is not marked as constexpr. This has been fixed in the libc++ trunk, and should appear in the next clang/libc++ release.
Hi, I defined BOOST_CHRONO_LIB_CONSTEXPR as follows to avoid this problem.
#if defined( BOOST_NO_CXX11_NUMERIC_LIMITS ) #define BOOST_CHRONO_LIB_CONSTEXPR #else #define BOOST_CHRONO_LIB_CONSTEXPR BOOST_CONSTEXPR #endif
Shouldn't BOOST_NO_CXX11_NUMERIC_LIMITS be defined as it doesn't providesa C++11 implementation, or should Boost.Chrono take in account the missing feature of libc++ individually?
I'm not sure what you are referring to with the word "it" in that sentence.
BTW, which version of libc++ are you using?
The one that ships with Xcode 4.5.2 - the most recent release from Apple. I don't believe that libc++ has a version number. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Le 06/01/13 00:06, Marshall Clow a écrit :
On Jan 5, 2013, at 2:45 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 05/01/13 18:37, Marshall Clow a écrit :
On Jan 4, 2013, at 11:25 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Updated release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. I built the RC on Mac OS X with both clang and gcc w/o errors. However, when I built using clang and libc++ in C++11 mode, I found two problems:
./b2 toolset=clang cxxflags="-std=c++11 -stdlib=libc++ -Wno-unused-variable" linkflags="-stdlib=libc++"
Issue #1:
clang-darwin.compile.c++ bin.v2/libs/chrono/build/clang-darwin-11/release/threading-multi/chrono.o In file included from libs/chrono/src/chrono.cpp:14: In file included from ./boost/chrono/detail/inlined/chrono.hpp:13: In file included from ./boost/chrono/chrono.hpp:11: ./boost/chrono/duration.hpp:353:49: error: constexpr function never produces a constant expression static BOOST_CHRONO_LIB_CONSTEXPR float lowest() BOOST_CHRONO_LIB_NOEXCEPT_OR_THROW ^ ./boost/chrono/duration.hpp:355:21: note: non-constexpr function 'max' cannot be used in a constant expression return -(std::numeric_limits<float>::max) (); ^ /usr/bin/../lib/c++/v1/limits:443:43: note: declared here _LIBCPP_INLINE_VISIBILITY static type max() _NOEXCEPT {return __base::max();} ^ This is a bug in libc++; std::numeric_limits<>::max() is not marked as constexpr. This has been fixed in the libc++ trunk, and should appear in the next clang/libc++ release. Hi, I defined BOOST_CHRONO_LIB_CONSTEXPR as follows to avoid this problem.
#if defined( BOOST_NO_CXX11_NUMERIC_LIMITS ) #define BOOST_CHRONO_LIB_CONSTEXPR #else #define BOOST_CHRONO_LIB_CONSTEXPR BOOST_CONSTEXPR #endif
Shouldn't BOOST_NO_CXX11_NUMERIC_LIMITS be defined as it doesn't providesa C++11 implementation, or should Boost.Chrono take in account the missing feature of libc++ individually? I'm not sure what you are referring to with the word "it" in that sentence. I meant if Boost.Config shouldn't not define BOOST_NO_CXX11_NUMERIC_LIMITS when using the libc++ as doesn't provide a compliant c++11 implementation.
Vicente
On Jan 5, 2013, at 4:05 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 06/01/13 00:06, Marshall Clow a écrit :
On Jan 5, 2013, at 2:45 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Shouldn't BOOST_NO_CXX11_NUMERIC_LIMITS be defined as it doesn't provides a C++11 implementation, or should Boost.Chrono take in account the missing feature of libc++ individually?
I'm not sure what you are referring to with the word "it" in that sentence. I meant if Boost.Config shouldn't not define BOOST_NO_CXX11_NUMERIC_LIMITS when using the libc++ as doesn't provide a compliant c++11 implementation.
I think that's an over-reaction. It's a bug. I'm not even sure that we should do anything about it; other than to note it and move on. Clang 3.2 is at RC3 stage, so I'm pretty sure that this will be fixed before we ship Boost 1.53.0 -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 6 January 2013 04:28, Marshall Clow <mclow.lists@gmail.com> wrote:
Clang 3.2 is at RC3 stage, so I'm pretty sure that this will be fixed before we ship Boost 1.53.0
I thought it was released with llvm 3.2.
On Jan 6, 2013, at 5:57 AM, Daniel James <dnljms@gmail.com> wrote:
On 6 January 2013 04:28, Marshall Clow <mclow.lists@gmail.com> wrote:
Clang 3.2 is at RC3 stage, so I'm pretty sure that this will be fixed before we ship Boost 1.53.0
I thought it was released with llvm 3.2.
Sorry - I missed the llvm 3.2 release announcement in the holiday mess; my bad. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 2013-01-05 23:06:34 +0000, Marshall Clow said:
This is a bug in libc++; std::numeric_limits<>::max() is not marked as constexpr. This has been fixed in the libc++ trunk, and should appear in the next clang/libc++ release.
I faced this issue when patching the HPX library to compile on OS X a few weeks ago. FWIW, the trunk version of libc++ *does* use constexpr in std::numeric_limits. It's mostly the Xcode shipped version that doesn't offer the support. In the meantime, the following is a good idea IMO:
BTW, which version of libc++ are you using?
The one that ships with Xcode 4.5.2 - the most recent release from Apple. I don't believe that libc++ has a version number.
Yes there is such a macro in libc++, the most recent version being: #define _LIBCPP_VERSION 1101 (See: http://llvm.org/svn/llvm-project/libcxx/trunk/include/__config) The version number has been updating somewhat inconsistently but according to the SVN history, constexpr support should be there since (_LIBCPP_VERSION >= 1002). $ svn log -r153888 ------------------------------------------------------------------------ r153888 | hhinnant | 2012-04-02 22:23:15 +0300 (Mon, 02 Apr 2012) | 1 line Update <limits> with constexpr support. Patch contributed by Jonathan Sauer. ------------------------------------------------------------------------ $ svn log -r164700 ------------------------------------------------------------------------ r164700 | hhinnant | 2012-09-26 18:38:09 +0300 (Wed, 26 Sep 2012) | 1 line Bump _LIBCPP_VERSION to 1002 ------------------------------------------------------------------------ I'd recommend having: #if defined(_LIBCPP_VERSION) #if _LIBCPP_VERSION < 1002 #define BOOST_NO_CXX11_NUMERIC_LIMITS #endif #endif -- Pyry Jahkola pyry.jahkola@iki.fi https://twitter.com/pyrtsa
On Jan 5, 2013, at 9:37 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Jan 4, 2013, at 11:25 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Updated release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I built the RC on Mac OS X with both clang and gcc w/o errors. However, when I built using clang and libc++ in C++11 mode, I found two problems:
./b2 toolset=clang cxxflags="-std=c++11 -stdlib=libc++ -Wno-unused-variable" linkflags="-stdlib=libc++"
Issue #1:
clang-darwin.compile.c++ bin.v2/libs/chrono/build/clang-darwin-11/release/threading-multi/chrono.o In file included from libs/chrono/src/chrono.cpp:14: In file included from ./boost/chrono/detail/inlined/chrono.hpp:13: In file included from ./boost/chrono/chrono.hpp:11: ./boost/chrono/duration.hpp:353:49: error: constexpr function never produces a constant expression static BOOST_CHRONO_LIB_CONSTEXPR float lowest() BOOST_CHRONO_LIB_NOEXCEPT_OR_THROW ^ ./boost/chrono/duration.hpp:355:21: note: non-constexpr function 'max' cannot be used in a constant expression return -(std::numeric_limits<float>::max) (); ^ /usr/bin/../lib/c++/v1/limits:443:43: note: declared here _LIBCPP_INLINE_VISIBILITY static type max() _NOEXCEPT {return __base::max();} ^
This is a bug in libc++; std::numeric_limits<>::max() is not marked as constexpr. This has been fixed in the libc++ trunk, and should appear in the next clang/libc++ release.
And it has been fixed in Xcode 4.6, released today. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
participants (9)
-
Charles_J_Wilson＠Dell.com -
Daniel James -
Eric Niebler -
Marshall Clow -
Olaf van der Spek -
Oliver Kowalke -
Pyry Jahkola -
Tom Kent -
Vicente J. Botet Escriba