boost libstdc++ issue (was libvisio error)

[David Evans]

On 9/6/15 9:24 AM, su_v wrote:
> On 2015-09-06 16:30 (+0200), David Evans wrote:
>> On 9/6/15 3:40 AM, su_v wrote:
>>> Didn't find a related ticket in trac yet, so I'm posting this here:
>>> Workaround applied successfully on OS X 10.7.5 (Xcode 4.6.3) to libvisio
>>> and libcdr in local port repo [1]:
>>>
>>> if {${configure.cxx_stdlib} eq "libstdc++"} {
>>>     configure.cppflags-append "-DBOOST_NO_CXX11_RVALUE_REFERENCES"
>>> }
>>>
>>> I do not know whether this is a "correct" solution - local tests however
>>> confirmed so far that the results are as expected. (...)
> 
>> I don't have a platform to test on Lion at this point so I wonder if
>> you could check and verify that this issue applies to all four
>> MacPorts ports libvisio, libvisio-0.1, libcdr, libcdr=0.1 and perhaps
>> librevenge separately?
> 
> These 2 built without any changes on Lion:
> - librevenge
> - libvisio
> 
> These 3 only built after applying above change:
> - libcdr
> - libcdr-0.1
> - libvisio-0.1
> 
> All ports have been tested after successful installation with their
> command line tool to convert CDR, VSD to XHTML, and viewing the result
> in Firefox.
> 
> 
> Regards, V
> 

Thanks, V.

After looking at the Boost code/documentation for a while this morning, I'm coming around to the theory that while using
your fix may work on a port by port basis, it's fixing the symptom rather than the root cause of the problem.

Boost uses BOOST_NO_CXX11_RVALUE_REFERENCES internally to switch code when the compiler in use doesn't support c++11
(c++0x) rvalue references.  When this macro is defined, boost disables code that uses rvalue references and either
emulates this functionality using pre-c++11 syntax or just disables the feature altogether.

Supposedly boost tests for compiler support during configuration and sets this macro if necessary in the boost headers.
Boost discourages the use of this and related macros in user code and reserves the right to change them without notice.

So the question is, why isn't this set by boost when compiling on Mac OS X configurations that use clang with
-stdlib=libstdc++ (Lion for instance).  Seems like there is possibly a mis-configuration in this case which could
have a wider effect more than just the ports referenced here.

This is just a working theory at this point, but if this is the case than it would probably be better to fix things
in boost itself rather than over-ride its configuration in each effected port.

Ryan, do you have any input on this?  I'm interested in the user.hpp that ${worksrcpath}/libs/config/configure generates
in this case. Does it define BOOST_NO_CXX11_RVALUE_REFERENCES? If so, perhaps the default clang configuration isn't
appropriate and a customized user.hpp needs to be employed?

http://www.boost.org/doc/libs/1_59_0/libs/config/doc/html/index.html#boost_config.configuring_boost_for_your_platform

Dave