boost libstdc++ issue (was libvisio error)

[su_v]

On 2015-09-07 11:20 (+0200), David Evans wrote:
> On 9/7/15 12:44 AM, su_v wrote:
>> On 2015-09-07 09:14 (+0200), David Evans wrote:
>>> 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

> 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.

Yes, it is required for git master of libvisio and libcdr too, at least
when compiling on OS X 10.7.5 with boost 1.59.

I redid the tests I had already done earlier after seeing the latest
commits upstream wrt boost 1.59 (i.e. comment out all boost-related
workarounds in the two devel portfiles, update port to latest git master
and build).


Tests with libvisio from git master:
====================================

1) all boost-related workarounds in portfile commented out:

build fails with:
> :info:build ./VSDXMLTokenMap.h:14:10: fatal error: 'tokens.h' file not found

(AFAICT 'tokens.h' is a generated file, which apparently is not
generated after the latest upstream commit - I don't know why. I also
tested variations of that commit, adding only
'-DBOOST_ERROR_CODE_HEADER_ONLY' or '-DBOOST_SYSTEM_NO_DEPRECATED' to
the CPPFLAGS in 'src/lib/Makefile.am': either way 'tokens.h' fails to be
generated.)


2) all boost-related workarounds in portfile commented out, last
upstream commit which claims to fix build with boost 1.59 reverted:

build fails with:
> :info:build ${prefix}/include/boost/thread/detail/move.hpp:31:10: fatal error: 'type_traits' file not found


3) enabling workaround '-DBOOST_NO_CXX11_RVALUE_REFERENCES',  last
upstream commit which claims to fix build with boost 1.59 reverted:

build fails with:
> :info:build Undefined symbols for architecture x86_64:
> :info:build   "boost::system::system_category()", referenced from:
> :info:build       __GLOBAL__I_a in VSDContentCollector.o
> :info:build       __GLOBAL__I_a in VSDXMLParserBase.o
> :info:build   "boost::system::generic_category()", referenced from:
> :info:build       __GLOBAL__I_a in VSDContentCollector.o
> :info:build       __GLOBAL__I_a in VSDXMLParserBase.o
> :info:build ld: symbol(s) not found for architecture x86_64
> :info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)


4) enabling both workarounds for boost in the portfile, last upstream
commit which claims to fix build with boost 1.59 reverted:

build succeeds.


Tests with libcdr from git master:
==================================

1) all boost-related workarounds in portfile commented out:

build fails with:
> :info:build ${prefix}/include/boost/thread/detail/move.hpp:31:10: fatal error: 'type_traits' file not found


2) enabling workaround '-DBOOST_NO_CXX11_RVALUE_REFERENCES':

buld fails with:
> :info:build Undefined symbols for architecture x86_64:
> :info:build   "boost::system::system_category()", referenced from:
> :info:build       __GLOBAL__I_a in libcdr-internal.a(CDRParser.o)
> :info:build   "boost::system::generic_category()", referenced from:
> :info:build       __GLOBAL__I_a in libcdr-internal.a(CDRParser.o)
> :info:build ld: symbol(s) not found for architecture x86_64
> :info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)


3) enabling both workarounds for boost in the portfile:

build succeeds.