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?

[emsrc]

I can confirm that I got exactly the same error as reported at the start of this thread (OS X 10.9.2).

[dmcc]

Thanks for the report, @emsrc. Have you tried installing g++ with MacPorts? I'm also curious if anyone has had any success using Homebrew instead of MacPorts to install g++.

[reckart]

I tried with the g++ from MacPorts that I have currently installed (g++-mp-4.7 (MacPorts gcc47 4.7.3_3) 4.7.3) using

CXX=g++-mp-4.7 make

This also gives me an error:

/opt/local/include/gcc47/c++/cstdlib:66:20: fatal error: stdlib.h: No such file or directory
compilation terminated.

[jimwhite]

I've made a PR to share my Mac OS X setup. I use MacPorts over Homebrew because of libLBFGS and because I use HTCondor (which are in the former but not the latter).

[dmcc]

Awesome, thanks @jimwhite! Great to have a branch that works for OS X users. I'd like to update the main README (and eventually the build process) with information about what users need to do to run on OS X. Am I right that it's these steps?

1. The four sudo port commands as a prerequisite
2. Changing GCC_FLAGS in the main Makefile
3. Adding -L/opt/local/lib to the beginning of LDFLAGS

In general, it seems like I should change the second-stage/programs/wlle/Makefile to not override various compiler flags

[jimwhite]

Yup. Basically just need to make sure we've got the compiler variables set and that they get down to all the subproject makefiles. I've streamlined the changes a bit and also chased down exactly what's going wrong. The -mno-avx fix is not the ideal solution but is good enough for now.

[jimwhite]

And yeah, you could merge the PR into a new branch (maybe MACOSX or such) which we can maintain as a simple starter for folks until a suitable solution for the master is sorted out.

[emsrc]

Works for me. Thanks a lot, @jimwhite!

[cielavenir]

Sorry for bumping (I found this thread in searching "clang stdio_filebuf").
Well, the easiest workaround for ext/stdio_filebuf.h is to use:
clang++ -stdlib=libstdc++ depending_on_filebuf.cpp. Of course this uses libstdc++ from gcc 4.2.1 and you cannot use some C++11 features.

[jimwhite]

Thanks for the tip, I'll look into it further when I'm back with my Maverick machine. I've been under the impression that there are other gcc-specific issues with this program, but if this stdlib fix will do the trick then that is definitely the way to go. I've got some other improvements to this PR that I'll be pushing in a few days in any case.

[dmcc]

Thanks for the information @cielavenir! @jimwhite, I'm curious to see if it helps on Maverick. At least on RHEL Linux, it doesn't seem to be enough to get clang++ to like best_parses (I get different auto_ptr-related errors when I use clang++).

[jimwhite]

I've polished up the PR and verified it works for both Mountain Lion and Mavericks on my MacBooks (both of which are Core i7) and still works on Linux. There are several key fixes in addition to using the MacPort of gcc. I've not tried out the clang/stdlib stuff and may not get to that after all because this setup is satisfactory for my purposes.

[cielavenir]

Then perhaps that should be better because we should not depend on ext/stdio_filebuf anyway.

I had a similar problem in my project and I used http://www.josuttis.com/cppcode/fdstream.html.
Anyway it seems there are no general solutions for this problem...
https://github.com/cielavenir/procon/blob/master/streambuf_fromfile.h

[cielavenir]

@dmcc I suppose you are trying to link libc++ .o and libstdc++ .o, which is not possible.

[dmcc]

With #44 and other changes, I'm hoping that BLLIP compiles with clang now.

Users with OS X who haven't installed gcc: Can you help test compilation? (ideally both for command line (make world) and Python (python setup.py build).

[L3viathan]

make world fails with ld: library not found for -lgomp (but the compilation itself seems to be working).

python setup.py build fails because I don't have swig (Error while running command: Command 'swig' not found.)

[dmcc]

Thanks for checking @L3viathan! If you run brew install libiomp and FOPENMP="-liomp5" make world does the command line version work?

For the Python side, I'm afraid compiling from the Git checkout will require swig (an eventual PyPI release will include the swig-generated files, though). Does brew install swig help? (I don't expect the Python side to build completely until we fix the command line side, though. There's a good chance I'll need to adjust setup.py to try to detect OS X.)

[L3viathan]

Brew-installed libiomp and ran it like you said, but it gave the same error.

The Python version seemed to work (i.e. didn't throw errors) but it didn't build completely, as you said.

[dmcc]

Does the fix mentioned in apache/mxnet#749 (comment) help the make world problem?

[L3viathan]

That means I do

brew install clang-omp
make CXX=clang-omp++ world

?
If so, no, it complains about a missing assert.h.

[dmcc]

@L3viathan, thanks for checking. @didzis, do you have any ideas?

[didzis]

@L3viathan, if you want to build with clang (recommended) and have the ld: library not found for -lgomp error, then you can try using libiomp directly by replacing the line FOPENMP = -fopenmp with FOPENMP=-liomp5 in the Makefile at the project root, and installing libiomp (brew install libiomp) if you didn't have it already installed (you will have it installed if you already tried the brew install clang-omp option). clang-omp depends on libiomp and is a lot heavier to install than just libiomp as it does recompile some heavy LLVM stuff.
Tested this on Yosemite (I don't have Mavericks machine at hand) - compiled without any errors. Tried this on older Lion too, got past this error, but failed due to incomplete libc++ implementation, so it must be fine with recent Xcode/clang version on Mavericks.

@dmcc, one of the recent commits (e0e34cf) introduced FOPENMP = -fopenmp into the Makefile. Clang doesn't support OpenMP or at least didn't support it out of box, but maybe it will change in future (https://clang-omp.github.io/ is now moved to http://openmp.llvm.org/).
Just by installing clang-omp (brew install clang-omp) isn't enough, as it still fails to build (at least for me): clang must be pointed to libiomp directly by setting FOPENMP=-liomp5. For now, I think, the fix would be to have an Apple/Darwing & Clang check in place to switch FOPENMP variable from -fopenmp to -liomp5.

[L3viathan]

@didzis It still doesn't work. I changed that flag, and afterwards when it didn't work also the other one (GCCFLAGS="-Wno-deprecated-declarations"), but both times it fails with clang: error: linker command failed with exit code 1 (use -v to see invocation)

During compilation, I noticed several clang: warning: -liomp5: 'linker' input unused warnings (but libiomp is definitely installed).

[dmcc]

@didzis Ah, I see. In e0e34cf#diff-b67911656ef5d18c4ae36cb6741b7965R83 I should have set FOPENMP ?= -fopenmp rather than just = so that environment variables can override it. I will put this in the next update (once we figure what else we need to change).

[didzis]

@L3viathan I tested it on a clean machine. Either you have a different libomp version installed (please check for any libomp/libiomp versions you might have in /usr/local/lib or wherever you brew puts libraries, I have libiomp5.dylib there), or your project tree might be dirty from previous build attempts.
I urge you to make a fresh clone of the repository and try to build it again from start.

That clang: warning: -liomp5: 'linker' input unused warning you can safely ignore, it's there because FOPENMP adds -fopenmp everywhere to compile time (it apparently works in a different way).

@dmcc That will help! Compiling with clang one must remember to correctly set FOPENMP, because the cause of the error is not apparent.

[L3viathan]

@didzis Before compiling I deleted the directory and re-cloned it. In /usr/local/lib I also only have brew's libiomp5.dylib (which has a timestamp from when I installed clang-omp a few days ago), though I admit this machine is anything but clean.

I don't really need bllip anymore, I'm just trying to help figure this out, since it was me who opened the issue originally. If it works for everyone else on OS X, I'm fine with that.

[didzis]

@L3viathan Maybe you have a different error, it's not possible to infer the real error from clang: error: linker command failed with exit code 1 (use -v to see invocation) alone. There must be something more.

[L3viathan]

@didzis Ah, sorry, it still doesn't find the library: ld: library not found for -liomp5. I assume that means it doesn't look in /usr/local/lib? Extending LDFLAGS with -L/usr/local/lib doesn't help either.

[didzis]

@L3viathan You can try this clang -Xlinker -v to see default library search paths, usually /usr/local/lib is there, if it's not - maybe you installed Command Line Tools without Xcode itself ?
Does the /usr/local/lib/libiomp5.dylib have correct permissions ?
Maybe it's a symbolic link, that has lost it's target ?
Can you check the output of file /usr/local/lib/libiomp5.dylib to be a correct binary for your system ?

[faisal33]

Hi dmcc and dizis - Did the bllip work for anyone using Clang in Yosemite? I can see the branch by Jim but was curious if you were successful with Clang.

[didzis]

Hi @faisal33 , it does work compiled with Clang in Yosemite, I do use the Python API.

[faisal33]

This is what I get when I try to install BLLIP with python in my mac. This same error continues to occur even after I changed from Clang to gcc using both brew and macports.

Command "/Users/faisalfayyaz/anaconda/bin/python -u -c "import setuptools, tokenize;file='/private/var/folders/sp/_jdn22fs7gd838jnh2rh65fr0000gn/T/pip-build-5T5Y8e/bllipparser/setup.py';exec(compile(getattr(tokenize, 'open', open)(file).read().replace('\r\n', '\n'), file, 'exec'))" install --record /var/folders/sp/_jdn22fs7gd838jnh2rh65fr0000gn/T/pip-E8ODa2-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /private/var/folders/sp/_jdn22fs7gd838jnh2rh65fr0000gn/T/pip-build-5T5Y8e/bllipparser

[didzis]

There is some extra effort needed to get it working with Clang on OS X:
you have to brew install libiomp first, and compile from the latest source using FOPENMP=-liomp5 make at the project root.
Anaconda comes with it's own LLVM stack (incl. Clang), so I'm not sure this will work with anaconda. It's possible that you will have to go some extra miles on anaconda with this.

[faisal33]

Hey Thanks I will definitely give it a try on Anaconda and see how it goes. Thank You for your input

[dmcc]

@faisal33 Thanks! Please let us know what you find as I'm sure others have this question as well.

[zilunpeng]

@L3viathan have your tried xcode-select --install after getting the assert.h error? that solved my problem

[L3viathan]

@zilunpeng I had the Xcode commandline tools installed already, so that didn't work. But for some reason (I assume something I did unrelated to this) compilation works for me now.

[juanmirocks]

My environment: OS X 10.11.5 (El Capitan), Python 3.5.1, and gcc installed through Homebrew.

The compiler seems to use clang regardless of whether I set:

CC=g++-6 && CXX=g++-6

Still, if I remove the flags -finline-functions and -fopenmp the compilation works (parser.sh works fine, and I also can do python setup.py install). This is how I modified the Makefile:

# CFLAGS ?= -MMD -O3 -Wall -ffast-math -finline-functions -fomit-frame-pointer -fstrict-aliasing $(FOPENMP) $(GCCFLAGS)
CFLAGS ?= -MMD -O3 -Wall -ffast-math -fomit-frame-pointer -fstrict-aliasing $(FOPENMP) $(GCCFLAGS)
LDFLAGS ?= $(GCCLDFLAGS) $(FOPENMP)
# FOPENMP ?= -fopenmp

Hope that helps

[juanmirocks]

When I set FOPENMP=-liomp5, even after installing brew install libiomp, compilation also works but I get the warning clang: warning: -liomp5: 'linker' input unused. So it seems negligible in my case

[didzis]

You don't have to set CC or CXX to g++ (it is clang anyway just with g++ headers) - clang is the default on OSX and bllip-parser will compile with clang if you install the libiomp5 library.

With recent homebrew versions the package has been moved: you now have to brew tap homebrew/boneyard first and then brew install libiomp.
After that you can compile with FOPENMP=-liomp5 make or FOPENMP=-fopenmp=libiomp5 make.

The second option won't give you the clang: warning: -liomp5: 'linker' input unused warning, but will give you a slightly different warning clang: warning: argument unused during compilation: '-fopenmp=libiomp5'; both can be safely ignored, it is just that not all compile commands use those options.

To build and install python library you have to do some extra steps.

[fhamborg]

Like what extra steps, @didzis ? I've been fighting against this bug here for a couple of hours now but didn't really make much progress.