tillt
commented
10 years ago Similar trap is leveldb which comes with snappy by default on homebrew. All of the above applies to that one as well.
Open tillt opened 10 years ago
tillt
commented
10 years ago Similar trap is leveldb which comes with snappy by default on homebrew. All of the above applies to that one as well.
When using preinstalled (homebew) versions of glog, gflags will be installed as a mandatory dependency. Which is fine in itself.
However, once you do another round of
../configure && makeon mesos, the bundled version of glog will autodetect the installed gflags library and will include some of its symbols. Due to the fact that mesos itself does not need gflags but links glog statically, there will be unresolvable symbols left in the resulting mesos library.In other words, preinstalled versions of glog that bind against gflags will break your standalone versions of the mesos library when being built using mesos' build system.
The proper workaround to this issue is forcing mesos to use the preinstalled version of glog instead of the bundled one. Such patch is currently in its make and should fix the problem nicely.
Until then, the only workaround is to uninstall glog/gflags before using the mesos build system again.
Another possible option is to ensure that mesos' bundled version of glog does not detect and use gflags. I have proposed such patch but that somehow never landed. I also proposed offering the option of not detecting to the glog upstream, but that will possibly share the fate of letters to santa claus.
Yet another option would be to force xcode-mesos to use the mesos bundled version of glog instead of using the homebrew installed one. As I simply did not like this option, I refrained from implementing it - but if you prefer that, go ahead and do so :) - just don't ask me for a pull-merge on that solution.