boost libstdc++ issue (was libvisio error)

[su_v]

On 2015-09-06 16:30 (+0200), David Evans wrote:
> On 9/6/15 3:40 AM, su_v wrote:
>> On 2015-09-05 17:40 (+0200), David Evans wrote:
>>> On 9/5/15 8:36 AM, David Evans wrote:
>>>> On 9/5/15 7:41 AM, echothevoid wrote:
>>>>> Hello!
>>>>>
>>>>> I  got an error after running regular sudo port upgrade outdatedcommand.
>>>>> The log tells me that:
>>>>> :info:build /opt/local/include/boost/thread/detail/move.hpp:31:10: fatal error: 'type_traits' file not found
>>>>> I have found a similar issue on: http://stackoverflow.com/questions/14104298/clang-boostspirit-and-c11 but do not know
>>>>> how to fix it in the macport's way.
>>>>> I am using 10.7.5 Lion, with Xcode version 4.6.3.
>>>>> The outcome of: 
>>>>> port installed | grep gcc
>>>>>   gcc49 @4.9.3_0 (active)
>>>>>   gcc_select @0.1_8 (active)
>>>>>   libgcc @5.2.0_0 (active)
>>>>>
>>>>> Can you suggest a newbie like me what to do next? 
>>>>>
>>>>> Many thanks,
>>>>> void
>>>>>
>>>>>
>>>>
>>>> As indicated in your stackoverflow.com reference, this is not a problem with libvisio per se but a problem with boost
>>>> when using libstdc++ (default c++ lib on Mac OS X earlier than 10.9).  This builds correctly on 10.9+ where libc++ is
>>>> the default.
>>>>
>>>> Now that trac is back up, suggest you file a ticket against boost including the information included in this message and
>>>> attach your log file there as well.  Don't forget to CC the boost maintainer.  He will probably want to file a bug
>>>> report upstream with the boost developers.
>>>>
>>>> port info --maintainer boost
>>>>
>>>> CCing the boost maintainer now for his info.
>>>
>>> Changing the subject.  Problem is when building with libstdc++.
>>
>> 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. Applied, successfully
>> compiled, installed and tested with libvisio (git master) as well as
>> libcdr (git master) on Lion: the command line tools of the libraries
>> produce expected results, and import in Inkscape using the shared
>> libaries also works (apart from a known regression in inkscape trunk
>> with CDR import not related to the recent boost upgrade).
>>
>>
>> Regards, V
>>
>>
>> [1] local portfiles (libvisio-devel, libcdr-devel):
>> http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/view/head:/ports/graphics/libvisio-devel/Portfile#L75
>> http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/view/head:/ports/graphics/libcdr-devel/Portfile#L71
> 

> Thanks for pointing out this fix but I'm a little bit confused. 
> You;re talking about libvisio and libcdr but your local 
> libvisio-devel and libcdr-devel ports appear to be correspond to the 
> latest MacPorts ports libvisio-0.1 and libcdr-0.1 but built from git 
> master. Am I correct?

Yes - the naming is due to legacy reasons: I started testing
librevenge-based versions of libcdr, libvisio and libwpg from git master
for inkscape before MacPorts had new ports for them, thus the local
devel ports had been based on the names used in the original MacPorts
portfiles. Later on, I did not bother to rename the devel ports (since
the local port repository is mostly used for testing, and not shared
elsewhere) - only the conflicts line was updated.

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

I can try to verify that - I do use MacPorts trunk though, installed
(without root privileges) into custom prefixes only, which might make
the results less conclusive for a default MacPorts installation or the
buildbots (if the one for Lion ever comes back).

> Which version(s) are you using to build Inkscape OSX releases? I'm
> planning to drop the older non-librevenge versions as soon as they
> are not needed by other dependents. Is this a problem for you?

The current stable Inkscape package for OS X (64bit only) includes the
librevenge-based versions, the same is planned for future releases.

Inkscape's autotools-based build system has checks for both versions: it
prefers the newer librevenge-based one and falls back to the older one:

http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_91_BRANCH/view/head:/configure.ac#L567
http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_91_BRANCH/view/head:/configure.ac#L607

If neither is found, the feature is disabled altogether.

Similar checks are in place for the (future) Cmake build system in
Inkscape trunk, but they have not been checked thoroughly yet how well
the fallback to older versions works (AFAICT it works ok with
librevenge-based versions of libvisio, libcdr and libwpg installed).

There is no need to further maintain the old versions of libcdr and
libvisio in MacPorts - at least wrt Inkscape.

> Thanks again for your help
> 
> Dave

Same :)

Regards, V