boost libstdc++ issue (was libvisio error)

[David Evans]

On 9/7/15 12:44 AM, su_v wrote:
> On 2015-09-07 09:14 (+0200), David Evans wrote:
> 
>> According to your results for the clang++ case the configuration used
>> was
>>
>>> //  Use this file to define a site and compiler specific
>>> //  configuration policy, this version was auto-generated by
>>> //  configure on Sun Sep  6 22:42:41 CEST 2015
>>> //  With the following options:
>>> //    CXX      = clang++
>>> //    CXXFLAGS = -I./../.. -I./../../libs/config/test -g -O2 -DBOOST_NO_CONFIG
>>> //    LDFLAGS  = 
>>> //    LIBS     = -lm -lpthread 
>>> //
>>
>> This seems ambiguous as to which library is being used libc++ or libstdc++.
>>
>> I wonder if you could run the clang++ test again first with -stdlib=libstdc++ appended to configure's own CXXFLAGS
>> as MacPorts does in the libvisio case and secondly with -stdlib=libc++ to see if that makes any difference.
> 
> Attached are the 'user.hpp' files created with these commands:
> 
> $ CXX='/usr/bin/clang++' CXXFLAGS='-stdlib=libstdc++' sh ./configure
> $ CXX='/usr/bin/clang++' CXXFLAGS='-stdlib=libc++' sh ./configure
> 
> 
> 
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
> 

Ok, this says that clang++ on Lion passes boost's test for rvalue reference support. This may be true. If so, then
disabling boost's support for it is not the right thing to do.

Going back to review the situation from the beginning, I looked at git master for libcdr and libvisio again.  I see that
the most recent commit in each claims to be a build fix for boost 1.59.  V, are you sure that your fix is required with
this most recent commit in place?  It uses a different set of boost defines.

Dave