#54 graphite2 1.2.0 build fails with -stdlib=libc++

[Ryan Carsten Schmidt]

If you put -stdlib=libc++ in CXXFLAGS, graphite2 1.2.0 fails to build with:

/usr/bin/../lib/c++/v1/utility:255:15: error: no viable overloaded '='
first = __p.first;
~~~~~ ^ ~~~~~~~~~

as reported to the MacPorts project here:

https://trac.macports.org/ticket/37947

This is not a problem on shipping versions of OS X because they use libstdc++ as the standard library.

[Martin Hosken]

Then don't build with -stdlib=libc++, graphite2 is carefully designed to not require libc++ and in fact has a test to check that it hasn't linked to it. Leaving the bug open in case there is another reason why it was felt necessary to add this.

[Jeremy Huddleston Sequoia]

Your comment makes no sense to me. We never said we were requiring libc++. We're saying that your code has bugs which prevent it from being built against libc++.

The graphite2 library itself works perfectly fine when linking against libc++.

The problem is just the featuremap test application.

[Ryan Carsten Schmidt]

Rumor has it libc++ will be the default on Apple's upcoming OS X 10.9 Mavericks, so if you want your software to continue to run on OS X in the future, you will have to build correctly with libc++.

[Martin Hosken]

Why should linking against libstdc++ (which we consciously avoid and have a test that fails if graphite is linked against libstdc++), cause a header file to fail? This bug is currently out of scope for us to deal with. Maybe we should wait until 10.9 to see whether they really are getting rid of libc (I would be surprised given the value of objective C to Apple) and requiring libstdc++. At that point we can look into why a difference in linkage should cause a .h file to blow up (esp. when we don't overload =). Seems like a C++ bug to me.

[Martin Hosken]

Hmm. This error occurs in a test file, so even if we get really stuck we can just avoid that test and I assume that the rest of the library has therefore built fine.
Looking at the particular source file, I notice that all system headers are loaded first, and that there are no C++ statements before the #includes and that fstream is number 3 on the list. So I would assume this would be replicable with a simple file consisting of:

include <cstdlib></cstdlib>

include <stdexcept></stdexcept>

include <fstream></fstream>

If so, then this is not a graphite problem, it's a C++ problem

Happy digging.

[Martin Hosken]

stupid clever formatter (oh it's markdown).

#include <cstdlib>
#include <stdexcept>
#include <fstream>

[Ryan Carsten Schmidt]

OS X 10.9 Mavericks was released in October. Unlike OS X 10.8 and earlier before it which used a version of libstdc++ as the system C++ library, 10.9 uses libc++.

When building graphite2 1.2.4 on such a system whose default C++ library is libc++, it fails, in the manner Jeremy described to you when he opened this ticket in February.

Passing -stdlib=libc++ on such a system is not necessary; it fails without that, since libc++ is now the default. But passing -stdlib=libc++ can show you the problem on older systems that do not default to libc++.

We are continuing in MacPorts to use the patch Jeremy committed to MacPorts in February, which removes the line featuring add_subdirectory(featuremap) from the file tests/CMakeLists.txt.

If you want graphite2 to build on OS X 10.9 and other newer systems that use libc++, you need to change graphite2's code. Thank you.

[Martin Hosken]

OK. Having the context as to why we have to link against libstdc++ more sense now. OTOH is it at all possible to just link against glibc? And would that make any difference to this bug anyway which looks to me to have nothing to do with the linker?

I'm afraid we have no OSX 10.9 to test on so we are reliant on you guys to help debug this one. I refer you to my reply of 13/9 where I listed the first 3 lines of the relevant file. You will notice that it simply includes 3 standard headers. If the C compiler can't handle that, I would humbly suggest that there is a problem somewhere in the C header stack. I don't see what we can do upstream to address this problem. Suggestions welcomed.

[Ryan Carsten Schmidt]

Whatever the problem was back in 2013, it has been fixed by now. We are able to build graphite2 on every version of macOS from 10.4 to 10.14, with libc++ or (now that graphite2 requires C++11) libstdc++ from a newer version of gcc. This bug report can be closed.