Mac OS X 10.9 (Mavericks) build issues

[David Evans]

Mac OS X 10.9 (Mavericks)
MacPorts 2.2.0
Xcode 5.0.1 (Build 5A2053 )
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Uses libc++ without TR1 namespace support

After applying patch suggested by Markus Engel that fixes another libc++ issue (attached), build of r12715 fails as follows:

In file included from selection-chemistry.cpp:103:
In file included from ./ui/tool/multi-path-manipulator.h:16:
./ui/tool/node.h:19:10: fatal error: 'tr1/functional' file not found
#include <tr1/functional>
                   ^
Although configure.ac checks for TR1 unordered_set usability and configures appropriately, it does not check for TR1 functional which is used unconditionally in the code. Libc++ is used in this version of Mac OS X which does not include support for TR1 namespace (functionality in std instead).

Any suggestions how best to fix this?

[Markus Engel (engelmarkus)]

The problem here is that libc++ has been written after c++11 was "released".
You could try this:

#if __cplusplus >= 201103L
#include <functional>
#else
#include <tr1/functional>
#endif

and compile with CXXFLAGS="-std=c++11".

[David Evans (devans-n)]

Ok, that helped. After applying tr1 fix (patch attached), compile fails again as follows

In file included from sp-guide.cpp:37:

./remove-last.h:15:34: error: calling a private constructor of class 'std::__1::__wrap_iter<SPGuideConstraint *>'

    typename vector<T>::iterator ii(&*i);

                                 ^

sp-guide.cpp:521:9: note: in instantiation of function template specialization 'remove_last<SPGuideConstraint>' requested here

        remove_last(att.item->constraints, SPGuideConstraint(guide, att.snappoint_ix));

Offending code in remove-list .h is this:

template<class T>
inline void remove_last(std::vector<T> &seq, T const &elem)
{
    using std::vector;

    typename vector<T>::reverse_iterator i(find(seq.rbegin(), seq.rend(), elem));
    g_assert( i != seq.rend() );
    typename vector<T>::iterator ii(&*i);
    seq.erase(ii);
}

[Markus Engel (engelmarkus)]

That's probably because you did not apply the correct patch in the first place :) . The "clang.patch" from bug #1232474 is about 19 kb in size, the one you attached in comment #1 is way too small. remove-last.h is definitely modified by it.

[David Evans (devans-n)]

Yes, you're right. After applying all the individual patches that were not already committed, the build was successful.

The results are contained in the attached patch (ignore the previously posted ones).

Successfully tested against r12742 using the following default compiler configurations

OS X 10.6 i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)
OS X 10.7 Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) -stdlib=libstdc++ -std=c++11
OS X 10.8 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) -stdlib=libstdc++ -std=c++11
OS X 10.9 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) -stdlib=libc++ -std=c++11

[Markus Engel (engelmarkus)]

I'm not sure whether all the changes I made in the original patch for FreeBSD are correct. So I'd suggest someone review the patch in comment #6. When everything is okay, we can commit the patch to trunk.

[Johan Engelen (johanengelen)]

hi Markus, thanks for your work. next time if you are not sure about some changes, make separate small patches. makes it easier to patch/commit

[Johan Engelen (johanengelen)]

(but I sure understand that makes it more work for you :-( )

[Johan Engelen (johanengelen)]

actually... just ignore my last two messages. I can easily apply the patch, and then commit on file-per-file basis. works fine.
thanks!

[Markus Engel (engelmarkus)]

@Johan: For me (OS X 10.6.8, clang-3.3 -std=c++11, libc++) compilation of the stable branch fails with the attached error. This seems to be a problem with libc++ and the iterator implementation there or with the adjustments you made to the patch before applying it.

[su_v (suv-lp)]

On 2013-11-12 23:44 +0100, Markus Engel wrote:
> For me (OS X 10.6.8, clang-3.3 -std=c++11, libc++) compilation of
> the stable branch fails with the attached error.

@Markus - issues with building stable are tracked in bug #1245722, please discuss issues with latest commits to lp:inkscape/0.48.x there, thx.

[Markus Engel (engelmarkus)]

Ah, I'm sorry.

[Johan Engelen (johanengelen)]

What about trunk right now Markus?

[David Evans (devans-n)]

Following up, I can confirm that r12809 builds on all MacPorts configurations listed in comment #6 including Mavericks. Thanks to all for your help.

Committed to MacPorts as port inkscape-devel @0.48.99.12809_0.
http://trac.macports.org/changeset/113341

[Nancy Poekert (ncp1113)]

This bug has cropped up again on a fresh build on OS X Mavericks. I made sure the source is up to date "Tree is up to date at revision 13294". This is the message I am getting on make:

Mac:src GTK$ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-am
  CXX selection-chemistry.o
In file included from selection-chemistry.cpp:105:
In file included from ./ui/tool/multi-path-manipulator.h:16:
./ui/tool/node.h:27:10: fatal error: 'tr1/functional' file not found
#include <tr1/functional>
         ^
1 error generated.
make[1]: *** [selection-chemistry.o] Error 1
make: *** [all] Error 2

[David Evans (devans-n)]

I believe this regression was caused by r13232 which needs to be reverted.

[su_v (suv-lp)]

@Nancy - AFAIK on Mavericks, with clang from latest Xcode, one needs to to compile with C++11 (see e.g. MacPorts 'inkscape-devel' Portfile for details). Did you specify the correct CXXLAGS?

[David Evans (devans-n)]

Actually both are required. Reverting r13232 is necessary to maintain compatibility with C++11 and libc++ which is used on Mavericks. The patch posted is currently being used on MacPorts to prevent this build regression.

[Nancy Poekert (ncp1113)]

I checked out the code from launchpad using bzr and I am using the instructions from the Inkscape Wiki to compile from source. I am running - make after the configure. I am assuming make is running the Makefile that was generated from automake. I am attaching that Makefile.

[su_v (suv-lp)]

@Nancy - unfortunately, the instructions in the wiki are very outdated (known issue, bug #1301187). For now, I would recommend to use MacPorts to install a recent trunk build (port: inkscape-devel).

[Nancy Poekert (ncp1113)]

I did use MacPorts and it compiled. Thanks for your help.

[su_v (suv-lp)]

On 2014-04-22 15:25 +0100, David Evans wrote:
> Reverting r13232 is necessary to maintain compatibility with C++11
> and libc++ which is used on Mavericks.

@David - would you mind filing a separate report about this build breakage of Inkscape trunk on Mavericks?

[su_v (suv-lp)]

On 2014-04-22 15:25 +0100, David Evans wrote:
> Reverting r13232 is necessary to maintain compatibility with C++11
> and libc++ which is used on Mavericks.

The part of the code which caused the build failure has been removed in revision
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13404>

Compiling Inkscape trunk on Mavericks should work again without requiring patches.