Compilation fails under OS X 10.9 (Mavericks)

[L3viathan]

While I have had the same problem that is described here, the suggested steps only brought me so far. The compiler doesn't find <ext/stdio_filebuf.h>, which, I'm sure, is because of changes by Apple in 10.9. Here's the relevant part of the output:

g++ -MMD -O3 -Wall -ffast-math -finline-functions -fomit-frame-pointer -fno-strict-aliasing -fPIC  Bchart.o BchartSm.o Bst.o FBinaryArray.o CntxArray.o ChartBase.o ClassRule.o ECArgs.o Edge.o EdgeHeap.o ExtPos.o Feat.o Feature.o FeatureTree.o Field.o FullHist.o GotIter.o InputTree.o Item.o Link.o Params.o ParseStats.o SentRep.o ScoreTree.o Term.o TimeIt.o UnitRules.o ValHeap.o edgeSubFns.o ewDciTokStrm.o extraMain.o fhSubFns.o headFinder.o headFinderCh.o utils.o MeChart.o  parseIt.o -o parseIt -D_REENTRANT -D_XOPEN_SOURCE=600 -lpthread
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C second-stage/programs/features best-parses
g++ -MMD -O3 -Wall -ffast-math -finline-functions -fomit-frame-pointer -fno-strict-aliasing -fPIC  -Wno-deprecated   -c -o best-parses.o best-parses.cc
In file included from best-parses.cc:50:
./popen.h:25:10: fatal error: 'ext/stdio_filebuf.h' file not found
#include <ext/stdio_filebuf.h>
         ^
1 error generated.
make[1]: *** [best-parses.o] Error 1
make: *** [reranker-runtime] Error 2

[dmcc]

Tricky to debug for me since I don't have access to any OS X machines. Do you know if ext/stdio_filebuf.h is anywhere on your system?

[L3viathan]

It is, in fact in multiple locations:

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/c++/4.2.1/ext/stdio_filebuf.h
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr/include/c++/4.2.1/ext/stdio_filebuf.h
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/c++/4.2.1/ext/stdio_filebuf.h
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1/ext/stdio_filebuf.h

I am running make with CXX=g++ make.

[dmcc]

Does this command help?

 CXX=g++ CXXFLAGS="-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1/" make

If so, those paths have somehow fallen out of the default include search path.

[L3viathan]

It didn't, I get the same error.

But if I add -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1/ to the definition of CXXFLAGS in the Makefile (as far as I understand it would get overwritten otherwise anyways), I get 5 new errors, which suggests g++ found the header file. The errors are these:

./tree.h:1102:16: error: no viable overloaded '='
./utility.h:556:20: error: call to function 'operator<<' that is neither visible in the template definition nor found by argument-dependent lookup
./spfeatures.h:426:10: error: invalid operands to binary expression ('basic_ostream<char, std::char_traits<char> >' and 'const std::pair<std::vector<int, std::allocator<int> >, std::vector<symbol, std::allocator<symbol> > >')
./spfeatures.h:489:16: error: invalid operands to binary expression ('basic_ostream<char, std::char_traits<char> >' and 'F' (aka 'pair<Is, Ss>'))
./utility.h:565:14: error: call to function 'operator>>' that is neither visible in the template definition nor found by argument-dependent lookup
1 warning and 5 errors generated.

The full error log seems to long to attach (warnings and notes are in there, too; if I'm wrong I can of course still put it here), so here it is on pastebin: http://pastebin.com/Vgv7euF4

[dmcc]

Very strange. Those error messages look like they came from clang++, not g++. In fact, if I search for no viable overloaded '=', I get back StackOverflow questions about clang. What does g++ --version print out for you?

[L3viathan]

I think you're on to something. It prints

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

even if I preface the command with CXX=g++

[dmcc]

Does this help? http://stackoverflow.com/questions/19535422/os-x-10-9-gcc-links-to-clang

[L3viathan]

I installed g++ with Macports, g++ --version also shows me that I'm actually using g++ (although I had to create a symlink because ports' g++ installs itself as g++-mp-4.9), but I get the same errors.

[dmcc]

Sounds like it might be some $PATH issue if you're still getting the same clang error messages but the real g++ is installed. This comment http://stackoverflow.com/questions/19535422/os-x-10-9-gcc-links-to-clang#comment31925721_19535472 implies you might (also?) need to run some macports command.

[dmcc]

Does the command succeed if you run the g++ command by hand in the directory in question?

That is, in second-stage/programs/features, if you run something like

g++ -MMD -O3 -Wall -ffast-math -finline-functions -fomit-frame-pointer -fno-strict-aliasing -fPIC  -Wno-deprecated -c -o best-parses.o best-parses.cc

[L3viathan]

It doesn't.

I selected GNU's g++ with macports, but g++ still points to clang. If I use g++-mp-4.9 in your command, I get:

In file included from best-parses.cc:45:0:
/opt/local/include/gcc49/c++/cassert:43:20: fatal error: assert.h: No such file or directory
 #include <assert.h>
                    ^
compilation terminated.

[dmcc]

Somehow even your g++-mp-4.9 seems to be acting like clang -- very strange. I'm afraid I don't know enough about development on OS X and can't really debug this remotely, but I have trouble believing that it's unsolvable.

On the other hand, I don't think there's much I can do on the BLLIP parser side (short of making BLLIP parser compile under clang which is a major undertaking) so I'm afraid I should close this issue for now.

[reckart]

Wouldn't it be plausible to leave the issue open as a "known issue" and close it when somebody has found a satisfactory solution?

[dmcc]

I guess I'm fine with that. It should probably be reported as an upstream bug (I suspect it already has). By the way, have other Mac OS X 10.9 users been able to replicate this?