[Lars Viklund]

boost\range\adaptor\formatted.hpp is missing an inline on line 154 for range_detail::formatted_holder formatted() This results in duplicate symbol linker errors in my project w/ VS2013.3RC.

[Eric Niebler]

I took the liberty of fixing this myself. I also removed the executable bit on boost/range.hpp. I hope Neil doesn't mind.

Back in 2007 when we made the same mistake in <tuple>, I added an "include all STL headers in two TUs" test to prevent it from happening again, which has served us perfectly. Does Boost have the same thing for each of its libraries? STL

On 22 Jul 2014 at 11:42, Eric Niebler wrote:

On 07/22/2014 10:13 AM, Stephan T. Lavavej wrote:

...

[Lars Viklund]

...

boost\range\adaptor\formatted.hpp is missing an inline on line 154 for range_detail::formatted_holder formatted() This results in duplicate symbol linker errors in my project w/ VS2013.3RC.

[Eric Niebler]

...

I took the liberty of fixing this myself. I also removed the executable bit on boost/range.hpp. I hope Neil doesn't mind.

Back in 2007 when we made the same mistake in <tuple>, I added an "include all STL headers in two TUs" test to prevent it from happening again, which has served us perfectly. Does Boost have the same thing for each of its libraries?

This is a good idea. I do it for xpressive, but I don't think there's anything comprehensive for all the boost libraries.

Agreed. I have this test too in AFIO, plus I cycle that test for everything headers only, AFIO headers only but ASIO not headers only, ASIO headers only but not AFIO headers only, and finally nothing headers only. I also cycle having one of the TUs use variadic templates and the other TU not. The reason for the dilligence is that I take advantage of inline virtual support/bug/misfeature when the compiler just happens to support it for headers-only builds, plus I keep forgetting to update the non-variadics support :( There is plenty of scope for unenforced errors to leak out if a CI doesn't help me. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Tue, Jul 22, 2014 at 07:49:41PM +0100, Neil Groves wrote:

On Tue, Jul 22, 2014 at 5:40 PM, Eric Niebler wrote:

...

I took the liberty of fixing this myself. I also removed the executable bit on boost/range.hpp. I hope Neil doesn't mind.

I am grateful that you did this. I missed the report due to the subject heading of the thread.

Sorry about not making it more visible, was going to file an actual bug about it, but the week has been slightly chaotic. -- Lars Viklund | zao@acc.umu.se

On 21 Jul 2014 at 6:59, Marshall Clow wrote:

...

...

Boost release 1.56.0 beta 1 is now available from SourceForge

Where does this put us as far as the schedule for the 1.56 final release?

We´re behind schedule; about 10 days. Assuming that we can get the problems that people are having with the beta fixed, I´d like to roll a release candidate early next week.

On Saturday I finally got AFIO building, though not testing, via the CI with Boost 1.56. That's 15 hours of effort porting AFIO and its soak testing CI to modular Boost, much of which was spent figuring out just how broken/different documentation generation and the b2 tool have become :( Anyway ... three of the build targets failed, and they are these: 1. https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Build%20NT_Win 64_VS2010/8/console 2. https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Build%20POSIX_ ARM_GCC%204.8/9/console (Barfs about flags -ftemplate-depth-128 and -x not being known) BTW, the following may be related: https://stackoverflow.com/questions/17714635/how-can-i-compile-boost-1 -54-0-1-54-for-the-ios-simulator-6-1-on-os-x-10-8-4 Looks like the bad GCC flags have been a problem for years. 3. https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Build%20POSIX_ ARM_clang%203.4/9/consoleFull (Over 22Mb of compiler warning and error spew, not least resulting from clang using the wrong ARM target and it generating illegal instructions) I'm happy to accept that VS2010 is being its usual self with C++ 11 code - roll on next year when I can drop V2010 after VS2014 comes out. But the ARM targets are more worrying - these are running Ubuntu 14.04 LTS on an nVidia Tegra K1 ARM Cortex A15 CI slave, so hardly ancient. GCC is 4.8.2 and clang is 3.4, both configured for arm-unknown-linux-gnueabihf. Yet Boost 1.56 is not compiling with default build options on ARM for either clang nor GCC - see the logs above. I also was surprised how badly broken clang is, so here is how it is being called: "clang++" -c -x c++ -O0 -g -fno-inline -Wall -g -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_ATOMIC_SOURCE -I"." -o "bin.v2/libs/atomic/build/clang-linux-3.4/debug/threading-multi/lockpo ol.o" "libs/atomic/src/lockpool.cpp" /tmp/lockpool-426fb3.s: Assembler messages: /tmp/lockpool-426fb3.s:165: Error: selected processor does not support ARM mode `ldrexb r1,[r0]' /tmp/lockpool-426fb3.s:167: Error: selected processor does not support ARM mode `strexb r2,r3,[r0]' /tmp/lockpool-426fb3.s:179: Error: selected processor does not support ARM mode `ldrexb r1,[r0]' /tmp/lockpool-426fb3.s:181: Error: selected processor does not support ARM mode `strexb r2,r3,[r0]' /tmp/lockpool-426fb3.s:197: Error: selected processor does not support ARM mode `ldrexb r1,[r0]' /tmp/lockpool-426fb3.s:199: Error: selected processor does not support ARM mode `strexb r2,r3,[r0]' /tmp/lockpool-426fb3.s:214: Error: selected processor does not support ARM mode `ldrexb r1,[r0]' /tmp/lockpool-426fb3.s:216: Error: selected processor does not support ARM mode `strexb r2,r3,[r0]' /tmp/lockpool-426fb3.s:233: Error: selected processor does not support ARM mode `ldrexb r1,[r0]' /tmp/lockpool-426fb3.s:235: Error: selected processor does not support ARM mode `strexb r2,r3,[r0]' clang: error: assembler command failed with exit code 1 (use -v to see invocation) That smells to me like ARM Ubuntu 14.04 has a badly configured clang? Thoughts? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Monday 21 July 2014 18:30:28 Niall Douglas wrote:

I also was surprised how badly broken clang is, so here is how it is being called:

"clang++" -c -x c++ -O0 -g -fno-inline -Wall -g -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_ATOMIC_SOURCE -I"." -o "bin.v2/libs/atomic/build/clang-linux-3.4/debug/threading-multi/lockpo ol.o" "libs/atomic/src/lockpool.cpp"

/tmp/lockpool-426fb3.s: Assembler messages: /tmp/lockpool-426fb3.s:165: Error: selected processor does not support ARM mode `ldrexb r1,[r0]' /tmp/lockpool-426fb3.s:167: Error: selected processor does not support ARM mode `strexb r2,r3,[r0]' /tmp/lockpool-426fb3.s:179: Error: selected processor does not support ARM mode `ldrexb r1,[r0]' /tmp/lockpool-426fb3.s:181: Error: selected processor does not support ARM mode `strexb r2,r3,[r0]' /tmp/lockpool-426fb3.s:197: Error: selected processor does not support ARM mode `ldrexb r1,[r0]' /tmp/lockpool-426fb3.s:199: Error: selected processor does not support ARM mode `strexb r2,r3,[r0]' /tmp/lockpool-426fb3.s:214: Error: selected processor does not support ARM mode `ldrexb r1,[r0]' /tmp/lockpool-426fb3.s:216: Error: selected processor does not support ARM mode `strexb r2,r3,[r0]' /tmp/lockpool-426fb3.s:233: Error: selected processor does not support ARM mode `ldrexb r1,[r0]' /tmp/lockpool-426fb3.s:235: Error: selected processor does not support ARM mode `strexb r2,r3,[r0]' clang: error: assembler command failed with exit code 1 (use -v to see invocation)

That smells to me like ARM Ubuntu 14.04 has a badly configured clang? Thoughts?

Boost.Atomic uses compiler macros to select the backend. Given that assembler- based ARM backends don't emit strexb/ldrexb, I suspect that the backend based on the __atomic* intrinsics is used. If the compiler is not able to compile these intrinsics and yet reports them as lock-free then this is a compiler bug that should be reported to clang team.

On 21 Jul 2014 at 18:30, Niall Douglas wrote:

2. https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Build%20POSIX_ ARM_GCC%204.8/9/console

(Barfs about flags -ftemplate-depth-128 and -x not being known)

BTW, the following may be related:

https://stackoverflow.com/questions/17714635/how-can-i-compile-boost-1 -54-0-1-54-for-the-ios-simulator-6-1-on-os-x-10-8-4

Looks like the bad GCC flags have been a problem for years.

I figured out the cause of this bug. What my CI was doing for bootstrap is this: ./bootstrap.sh --with-toolset=clang Why? Because FreeBSD 10 doesn't come with gcc, but all my other targets always have clang. So I always bootstrapped with clang. Unfortunately, this breaks: ./b2 toolset=gcc ... iff you bootstrapped with clang! ./b2 toolset=clang works fine though. Reported to https://svn.boost.org/trac/boost/ticket/10258. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/