Ok, I didn't really think so, since there is a distinct lack of
further discussions of the issue on the mailing lists.
Unfortunately this issue probably stops me from using C++11 at all, at
least until GCC changes their default and some of the larger distros
have started using that version of GCC.
So C++11 is at least a few years away for me, it seems
:-(
/Lars
On Wed, Jan 22, 2014 at 9:22 AM, Andrey Semashev
On Wed, Jan 22, 2014 at 12:16 PM, Lars Hagström
wrote: On Mon, May 20, 2013 at 2:15 PM, Andrey Semashev
wrote: On Mon, May 20, 2013 at 3:44 PM, Petr Machata
wrote: I maintain Boost in Fedora, and C++03/11 incompatibility has been on my list of things to look into for some time now.
2. Compile different versions of Boost libraries
I'm not sure how this fares with respect to autotools (by any name). We might need to update some automation to adapt to the changes in soname mangling, and to take any C++11-enabling switches into account. But I didn't look closely. Covering autotools and cmake would take us a long way towards the goal, which seems doable, so maybe #2 is the way to go.
Great, nice to hear from package maintainers. I got the same impression from the discussion, so maybe I'll try to implement a Boost.Build property to select C++ flavor.
However, I don't know much about autotools or cmake internals, so I can't tell how it will affect them.
Did you ever get anywhere with this? This issue has bitten me now, and I would really like to avoid having to build custom boost versions on Linux. The ease of installation when using the distro repos is *so* nice.
No, not really. I had a few quick attempts that failed because of my incompetence with Boost.Build and then I got distracted.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost