Issues when installing drake in M1 macOS - drake

I follow the steps in the webpage, a problem came out when executing./setup/mac/install_prereqs.sh
drake % ./setup/mac/install_prereqs.sh
+ binary_distribution_args=()
+ source_distribution_args=()
+ '[' '' '!=' '' ']'
+ source ./setup/mac/binary_distribution/install_prereqs.sh ''
++ set -euxo pipefail
++ with_update=1
++ '[' '' '!=' '' ']'
++ [[ 501 -eq 0 ]]
++ command -v conda
++ command -v brew
++ [[ -z '' ]]
++ export HOMEBREW_NO_AUTO_UPDATE=1
++ HOMEBREW_NO_AUTO_UPDATE=1
++ export HOMEBREW_NO_INSTALL_CLEANUP=1
++ HOMEBREW_NO_INSTALL_CLEANUP=1
++ binary_distribution_called_update=0
++ [[ 1 -eq 1 ]]
++ brew update
Already up-to-date.
++ binary_distribution_called_update=1
++ brew tap robotlocomotion/director
+++ cat
++ brew uninstall --force robotlocomotion/director/scipy#1.5.4 robotlocomotion/director/numpy#1.19.4
++ brew bundle --file=./setup/mac/binary_distribution/Brewfile --no-lock
Using dreal-deps/ibex
Using robotlocomotion/director
Using adoptopenjdk
Using clp
Using cmake
Using double-conversion
==> Installing ibex#2.7.4 from dreal-deps/ibex
==> Downloading https://github.com/dreal-deps/ibex-lib/archive/ibex-2.7.4_10.tar.gz
Already downloaded: /Users/marui/Library/Caches/Homebrew/downloads/cf1b94f6783b4d23cc0bd34c10833f34cea5e7cff82ddfa24d7613f439a9d7f2--ibex-lib-ibex-2.7.4_10.tar.gz
==> ./waf configure --prefix=/opt/homebrew/Cellar/ibex#2.7.4/2.7.4_10 --enable-shared --with-optim --with-solver --with-affine-extended --interval-lib=filib --lp-lib=clp --clp-path=/opt/homebrew/opt/clp
Last 15 lines from /Users/marui/Library/Logs/Homebrew/ibex#2.7.4/01.waf:
Checking for program 'make' : /opt/homebrew/Library/Homebrew/shims/mac/super/make
Applying patch : filibsrc-3.0.2.2.all.all.patch
Calling configure : done
Calling make : done
Calling install : done
Checking for header interval/interval.hpp : yes
Checking for library prim : yes
Checking for compiler flags -frounding-math : yes
Checking for compiler flags -ffloat-store : yes
Checking for header interval/interval.hpp with -msse3 : yes
Configuration of the library for LP
Library for LP : clp
Checking for 'clp' : not found
The configuration failed
(complete log in /private/tmp/ibex-2.7.4-20210319-75719-hq0bkg/ibex-lib-ibex-2.7.4_10/__build__/config.log)
Do not report this issue to Homebrew/brew or Homebrew/core!
Installing dreal-deps/ibex/ibex#2.7.4 has failed!
Using eigen
Using gcc
Using fmt
Using gflags
Using glew
Using glib
Using graphviz
Using ipopt
Using libyaml
Using lz4
Using nlopt
Using numpy
Using openblas
Using pkg-config
Using python#3.9
Using scipy
Using spdlog
Using suite-sparse
Using tinyxml
Using tinyxml2
Using robotlocomotion/director/vtk#8.2.0
Using xz
Using yaml-cpp
Using zeromq
Homebrew Bundle failed! 1 Brewfile dependency failed to install.
How can i fix this? Thanks in advance.

The official answer: "On macOS, x86_64 is the only supported architecture and running Drake under Rosetta 2 emulation on arm64 is not supported." -- https://drake.mit.edu/developers.html#supported-configurations as of 2021-03-18.
You can subscribe to https://github.com/RobotLocomotion/drake/issues/14555 for any updates regarding M1 support.
However, if you want to try to hack through it locally, you could try commenting out homebrew dependencies that do not succeed (e.g., IBEX in this case).
With IBEX disabled, you'll also have to bazel build --define=NO_DREAL=ON to disable dReal for the moment. Likely, other dependencies will also fail, but we have not tested on M1 yet so we don't know how close it is to working.
I've filed https://github.com/dreal/homebrew-dreal/issues/10 in case we can fix the IBEX problem easily.
The other option would be to spin up an Ubuntu VM (based on either 18.04 or 20.04).

Related

How to install llvm#13 with Homerew on macOS High Sierra 10.13.6? Got "Built target lldELF" error

Although High Sierra is no longer supported by Homebrew, but I need to install llvm#13 formula as a dependency for other formulas. So I tried to install it this way:
$ brew install llvm
...
==> Downloading https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.0/llvm-project-13.0.0.src.tar.xz
Already downloaded: /Users/username/Library/Caches/Homebrew/downloads/8fd68fc8f968137c5080826db6e58682326235960fd8469363eb27d0799978ca--llvm-project-13.0.0.src.tar.xz
...
==> Installing llvm
==> cmake -G Unix Makefiles .. -DLLVM_ENABLE_PROJECTS=clang;clang-tools-extra;lld;lldb;mlir;polly -DLLVM_ENABLE_RUNTIMES=compiler-rt;libcxx;libcxxabi;libunwind;openmp -DLLVM_POLLY_L
==> cmake --build .
...
[ 79%] Built target lldELF
make: *** [all] Error 2
An error is occurred after a long time of compilation. I also found this error in ~/Library/Logs/Homebrew/llvm/02.cmake:
/tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm:246:52: error: use of undeclared identifier 'CPU_SUBTYPE_ARM64E'
if (cputype == CPU_TYPE_ARM64 && cpusubtype == CPU_SUBTYPE_ARM64E) {
^
1 error generated.
make[2]: *** [tools/lldb/source/Host/macosx/objcxx/CMakeFiles/lldbHostMacOSXObjCXX.dir/HostInfoMacOSX.mm.o] Error 1
make[1]: *** [tools/lldb/source/Host/macosx/objcxx/CMakeFiles/lldbHostMacOSXObjCXX.dir/all] Error 2
How can I fix that compilation error?
Install llvm with debug mode enabled:
$ brew install --debug llvm
Installation process encounters with the same error mentioned in the question, but some options are provided to fix the issue. Choose option 5:
- raise
- ignore
- backtrace
- irb
- shell
Choose an action: 5
It gives a shell access to the current build directory of llvm formula. Find the current folder:
$ pwd
/private/tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src
Change the location to the build directory:
cd llvm/build
Edit the HostInfoMacOSX.mm and remove the second part of condition:
vi ../../lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
You need to change the line 246 from:
if (cputype == CPU_TYPE_ARM64 && cpusubtype == CPU_SUBTYPE_ARM64E) {
to:
if (cputype == CPU_TYPE_ARM64) {
Then re-run the last command:
$ cmake --build .
It takes some time to be completed:
...
[100%] Linking CXX executable ../../../../bin/lldb-vscode
cd /tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/tools/lldb/tools/lldb-vscode && /usr/local/Cellar/cmake/3.21.4/bin/cmake -E cmake_link_script CMakeFiles/lldb-v
scode.dir/link.txt --verbose=1
/usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang++ -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wn
o-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-c
lass-memaccess -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wno-deprecated-declarations -Wno-unkn
own-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O3 -DNDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++ -Wl,-sectcreate,__
TEXT,__info_plist,/tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/tools/lldb/tools/lldb-vscode/lldb-vscode-Info.plist -Wl,-dead_strip CMakeFiles/lldb-vscode.dir/
lldb-vscode.cpp.o CMakeFiles/lldb-vscode.dir/BreakpointBase.cpp.o CMakeFiles/lldb-vscode.dir/ExceptionBreakpoint.cpp.o CMakeFiles/lldb-vscode.dir/FifoFiles.cpp.o CMakeFiles/lldb-vsc
ode.dir/FunctionBreakpoint.cpp.o CMakeFiles/lldb-vscode.dir/IOStream.cpp.o CMakeFiles/lldb-vscode.dir/JSONUtils.cpp.o CMakeFiles/lldb-vscode.dir/LLDBUtils.cpp.o CMakeFiles/lldb-vsco
de.dir/OutputRedirector.cpp.o CMakeFiles/lldb-vscode.dir/ProgressEvent.cpp.o CMakeFiles/lldb-vscode.dir/RunInTerminal.cpp.o CMakeFiles/lldb-vscode.dir/SourceBreakpoint.cpp.o CMakeFi
les/lldb-vscode.dir/VSCode.cpp.o -o ../../../../bin/lldb-vscode -Wl,-rpath,#loader_path/../lib ../../../../lib/liblldb.13.0.0.dylib -lpthread ../../../../lib/libclang-cpp.dylib ../
../../../lib/libLLVM.dylib
[100%] Built target lldb-vscode
/usr/local/Cellar/cmake/3.21.4/bin/cmake -E cmake_progress_start /tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/CMakeFiles 0
Then run the install command:
$ cmake --build . --target install
The tail of the result should be:
...
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./CheckAtomic.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./FindSphinx.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./FindGRPC.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./TableGen.cmake
Execute the last command:
$ cmake --build . --target install-xcode-toolchain
The tail of the results should be:
...
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./CheckAtomic.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./FindSphinx.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./FindGRPC.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./TableGen.cmake
Built target install-xcode-toolchain
/usr/local/Cellar/cmake/3.21.4/bin/cmake -E cmake_progress_start /tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/CMakeFiles 0
Then press control+d to return to debug menu. Because the two last commands were run manually, you need to ignore the rest of errors by choosing the option 2:
- raise
- ignore
- backtrace
- irb
- shell
Choose an action: 2
==> cmake --build . --target install
...
cmake
--build
.
--target
install
Error: could not load cache
BuildError: Failed executing: cmake --build . --target install
1. raise
2. ignore
3. backtrace
4. irb
5. shell
Choose an action: 2
==> cmake --build . --target install-xcode-toolchain
...
cmake
--build
.
--target
install-xcode-toolchain
Error: could not load cache
BuildError: Failed executing: cmake --build . --target install-xcode-toolchain
1. raise
2. ignore
3. backtrace
4. irb
5. shell
Choose an action: 2
It will continue to install to the rest:
==> Fixing /usr/local/Cellar/llvm/13.0.0_1/bin/FileCheck permissions from 755 to 555
==> Fixing /usr/local/Cellar/llvm/13.0.0_1/bin/analyze-build permissions from 755 to 555
...
==> Changing dylib ID of /usr/local/Cellar/llvm/13.0.0_1/lib/libunwind.1.0.dylib
from #rpath/libunwind.1.dylib
to /usr/local/opt/llvm/lib/libunwind.1.dylib
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FromPathLoader): loading /usr/local/opt/llvm/.brew/llvm.rb
==> Caveats
To use the bundled libc++ please add the following LDFLAGS:
LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
llvm is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.
If you need to have llvm first in your PATH, run:
echo 'export PATH="/usr/local/opt/llvm/bin:$PATH"' >> ~/.zshrc
For compilers to find llvm you may need to set:
export LDFLAGS="-L/usr/local/opt/llvm/lib"
export CPPFLAGS="-I/usr/local/opt/llvm/include"
==> Summary
🍺 /usr/local/Cellar/llvm/13.0.0_1: 10,907 files, 1.8GB, built in 1418 minutes 39 seconds
It can be verified this way, the default llvm#10 pre-installed:
$ /usr/bin/clang --version
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
And the new Homebrew version of llvm#13:
$ /usr/local/opt/llvm/bin/clang --version
Homebrew clang version 13.0.0
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
#HamidRohani provides a great solution for those still tinkering in High Sierra (10.13). Getting a recent version of LLVM to compile on my old MAC with an older XCode (clang version 10.0.1 in my case) was a great help. My nominal contribution...
Alternatively, you could define the symbol after line 41 in HostInfoMacOSX.mm:
// Kludge: Symbol definition extracted from a modern machine.h
#ifndef CPU_SUBTYPE_ARM64E
# define CPU_SUBTYPE_ARM64E ((cpu_subtype_t) 2)
#endif
Now, there's no need to modify line 246. And the definition would resolve any (possible) subsequent references. And let me aggregate the steps shown above conducted in brew's debug-shell:
cmake . -DLLVM_CREATE_XCODE_TOOLCHAIN=On
cmake --build .
cmake --build . --target install
cmake --build . --target install-xcode-toolchain
Regarding the LLVM-related variable, setting LLVM_CREATE_XCODE_TOOLCHAIN to On directs CMake to generate a target named 'install-xcode-toolchain'. 1 The target is a work-around to System Integrity Protection (SIP); "Xcode toolchains are a mostly-undocumented feature that allows multiple copies of low level tools to be installed to different locations, and users can easily switch between them." 2
Brew's Caveats
Brew gives you few caveats necessary to use the new compiler: "because macOS already provides this software and installing another version in parallel can cause all kinds of trouble." To use your new compiler, "You need to have llvm first in your PATH and for compilers to find llvm you may need to set" LDFLAGS and CDFLAGS. But since these gems-of-wisdom appear near the end of a million-lines of output, let me re-iterate here:
export PATH="/usr/local/opt/llvm/bin:$PATH"
export LDFLAGS="-L/usr/local/opt/llvm/lib"
export CPPFLAGS="-I/usr/local/opt/llvm/include"
Setting PATH is straight forward. I however, didn't need to set LDFLAGS or CPPFLAGS. Further, no joy with this additional caveat, "To use the bundled libc++ please add the following LDFLAGS":
export LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
Anyway, moving on... To demonstrate that all's good, a C++ foo program that incorporates <filesystem>; a library not in High Sierra:
#include <iostream>
// C++17: Modern C++ compiler has std filesystem
#include <filesystem>
namespace fs = std::filesystem;
typedef std::filesystem::path my_path;
using namespace std;
int main ()
{
fs::path path{"/tmp"};
path /= "foo.txt";
ofstream ofs(path);
ofs << "Hello World." << endl;
ofs.close();
return 0;
}
Clearly, a nonsensical program, But to compile:
unset CPPFLAGS
unset LDFLAGS
clang++ -std=c++17 -L/usr/local/opt/llvm/lib foo.cpp -o foo
Again, showing That I didn't need CPPFLAGS and LDFLAGS. And so, The executable links to the correct libc++ library:
MacIntel:c++fs mjo$ otool -L foo
foo:
/usr/local/opt/llvm/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
Enjoy.

Error installing Ruby on Ubuntu 14.04

The following install commands:
gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
\curl -sSL https://get.rvm.io | bash -s stable --rails
Returns this error:
Installing requirements for ubuntu.
Updating system................
Error running 'requirements_debian_update_system ruby-2.2.1',
showing last 15 lines of /home/gav/.rvm/log/1458060663_ruby- 2.2.1/update_system.log ++ /scripts/functions/logging : rvm_pretty_print() 78 > case "${TERM:- dumb}" in ++ /scripts/functions/logging : rvm_pretty_print() 81 > case "$1" in
++ /scripts/functions/logging : rvm_pretty_print() 83 > [[ -t 2 ]]
++ /scripts/functions/logging : rvm_pretty_print() 83 > return 1
++ /scripts/functions/logging : rvm_error() 117 > printf %b 'There has been error while updating '\''apt-get'\'', please give it some time and try again later.
404 errors should be fixed for rvm to proceed. Check your sources configured in:
/etc/apt/sources.list
/etc/apt/sources.list.d/*.list
\n'
There has been error while updating 'apt-get', please give it some time and try again later.
404 errors should be fixed for rvm to proceed. Check your sources configured in:
/etc/apt/sources.list
/etc/apt/sources.list.d/*.list
++ /scripts/functions/requirements/ubuntu : requirements_debian_update_system() 53 > return 100
Requirements installation failed with status: 100.
You have problems with your sources
heres one solution, open a terminal type in
sudo apt-get update
take note of the names that are causing the 404s, errors, etc.
then open your software center and choose sources
there pick "Other Software" (second tab)
expand that window and start disabling the repositories that cause you trouble
as you uncheck any repositories, try again
sudo apt-get update
until you see no errors
make sure you don't see any errors or not found sources
afterward type in
source ~/.rvm/scripts/rvm
and
rvm requirements
and That's it...

ejabber's erl file give error "segmentation fault: 11" while running on mac os 10.7.5

I am trying to start ejabber 16.05 server on mac os 10.7.5. while starting up, it gives error. on further investigation, I found that "erl" executor file shipped with ejabber is throwing "Segmentation Fault:11" while running independently. I firmly believe that resolving issue with "erl" file execution will solve server start up issue. can anyone please help. Below is the code from "erl" that is causing segmentation fault error
#!/bin/sh
ROOTDIR=/Applications/ejabberd-15.06
export ROOTDIR
BINDIR=$ROOTDIR/bin
export BINDIR
EMU=beam
export EMU
PROGNAME=$BINDIR/erl
export PROGNAME
PATH=$BINDIR:$PATH
export PATH
arch() {
case `uname -m` in
i[3456]86 ) echo x86 ;;
i86pc) echo x86 ;;
armv7*) echo armhf ;;
arm*l) echo armel ;;
* ) echo `uname -m | tr A-Z a-z` ;;
esac
}
os=`uname -s | tr A-Z a-z`
cpu=`arch`
ARCHDIR=${os}-${cpu}
export ARCHDIR
# Dynamic libraries
LD_LIBRARY_PATH=$ROOTDIR/lib/$ARCHDIR
export LD_LIBRARY_PATH
DYLD_LIBRARY_PATH=$LD_LIBRARY_PATH
export DYLD_LIBRARY_PATH
exec $BINDIR/erlexec ${1+"$#"}
I just see that you are using OSX 10.7. We do not test ejabberd binary installer on version of OS that are so old.
I do not even expect the binary installer to run on such an old release.
If you have to run ejabberd on that OSX version, you have to build it from source.
ejabberd source are available on official ejabberd Github.
Documentation for installation and build is here Installing ejabberd from source code.

Erlang Build Fails: Can not link the wx driver, wx will NOT be useable

./configure returns an error message when run:
wx:Can not link the wx driver, wx will NOT be useable
When I run .\configure | grep wx, the logs are as follows:
configure: configuring in wx/.
configure: running /bin/bash '/home/nihal/Downloads/otp_src_17.1/lib/wx/./configure' --prefix=/usr/local '--prefix=/usr/local' 'ERL_TOP=/home/nihal/Downloads/otp_src_17.1' '--cache-file=/dev/null' '--srcdir=/home/nihal/Downloads/otp_src_17.1/lib' --cache-file=/dev/null --srcdir=/home/nihal/Downloads/otp_src_17.1/lib/wx/.
rm: remove write-protected regular file './CONF_INFO'?
checking for debug build of wxWidgets... checking for wx-config... /usr/bin/wx-config
checking for wxWidgets version >= 2.8.4 (--unicode --debug=yes)... yes (version 2.8.12)
checking for wxWidgets static library... no
checking for standard build of wxWidgets... checking for wx-config... (cached) /usr/bin/wx-config
checking for wxWidgets version >= 2.8.4 (--unicode --debug=no)... yes (version 2.8.12)
checking for wxWidgets static library... no
checking if wxwidgets have opengl support... yes
checking for wx/stc/stc.h... yes
checking if we can link wxwidgets programs... yes
wx : Can not link the wx driver, wx will NOT be useable
How do I successfully build it?
If you don't need wx, you can build Erlang without it with:
./configure --without-wx
If you need wx support, see instructions at Building with wxErlang section.
Check the contents of the $ERL_TOP/lib/wx/config.log file for a possible cause.
In my case, I was missing the c++ compiler. After installing g++ I was able to compile and install OTP with no further problems.
I got the same error while building erlang on CentOS 7.
I too was missing the C++ compiler.
After doing yum install gcc-c++, I was able to build erlang successfully.

Errors due to vowpal wabbit's dependencies on boost library

I'm trying real hard to install vowpal wobbit and it fails when i run the make file, throwing:
cd library; make; cd ..
g++ -g -o ezexample temp2.cc -L ../vowpalwabbit -l vw -l allreduce -l boost_program_options -l z -l pthread
ld: library not found for -lboost_program_options collect2: ld returned 1 exit status make[1]: *** [ezexample] Error 1'
I then added the links to the boost library here by specifying -L/usr/local/lib
Now I get the following error:
g++ -g -o ezexample temp2.cc -L/usr/local/lib ../vowpalwabbit -l vw -l allreduce -l boost_program_options -l z -l pthread
ld: library not found for -lvw
collect2: ld returned 1 exit status
make: *** [ezexample] Error 1
I happened to get everything working on OS X 10.7 as follows:
Make sure you have a working Boost installation. As indicated on the Getting started page, usually we only need header files, but some Boost libraries must be built separately, including the program_options library which is used to process options from command line or config file. Go into your boost folder, and then at your shell prompt:
$ ./bootstrap.sh
$ ./bjam
This will compile and build everything. You should now have a bin.v2/ directory in your boost directory, with all built libraries for your system (static and threaded libs).
$ ls bin.v2/libs/
date_time iostreams python serialization test
filesystem math random signals thread
graph program_options regex system wave
More importantly, extra Boost libraries are made available in the stage/lib/ directory. For me, these are Mach-O 64-bit dynamically linked shared library x86_64.
The include path should be your_install_dir/boost_x_xx_x, where boost_x_xx_x is the basename of your working Boost. (I personally have boost_1_46_1 in /usr/local/share/ and I symlinked it to /usr/local/share/boost to avoid having to remember version number.) The library path (for linking) should read your_install_dir/boost_x_xx_x/stage/lib. However, it might be best to symlink or copy (which is what I did) everything in usual place, i.e. /usr/local/include/boost for header files, and /usr/local/lib for libraries.
Edit the Makefile from the vowpal_wabbit directory, and change the include/library paths to reflect your current installation. The Makefile should look like this (first 12 lines):
COMPILER = g++
UNAME := $(shell uname)
ifeq ($(UNAME), FreeBSD)
LIBS = -l boost_program_options -l pthread -l z -l compat
BOOST_INCLUDE = /usr/local/include
BOOST_LIBRARY = /usr/local/lib
else
LIBS = -l boost_program_options -l pthread -l z
BOOST_INCLUDE = /usr/local/share/boost # change path to reflect yours
BOOST_LIBRARY = /usr/local/share/boost/stage/lib # idem
endif
Then, you are ready to compile vowpal_wabbit (make clean in case you already compiled it):
$ make
$ ./vw --version
6.1
$ make test
You can also install vowpal wabbit on OS X using brew:
brew install vowpal-wabbit
Or you can just install boost, and then install vw from the github repo.
brew install boost
For installation on CentOS 7 (6.5 perl version is too old for latest vw source code), I've found the instructions at http://wkoplitz.blogspot.be/2012/12/vowpal-wabbit-on-centos.html to work fine:
yum install zlib-devel boost-devel
yum groupinstall "Development Tools"
git clone git://github.com/JohnLangford/vowpal_wabbit.git
cd vowpal_wabbit
./autogen.sh
make
make test
Good news:
As of the latest release VowpalWabbit version 9.1.0, vw no longer relies on Boost program_options
From the release highlights:
Removal of Boost Program Options dependency
For a long time we have depended on Boost Program Options
for command line options parsing. In this release, we have > replaced this dependency with our own implementation of
command line parsing. Apart from one place where we depend > on Boost Math in standalone mode, this means that VW core
and the command line tool are free of Boost dependencies
hopefully making the code a bit easier to build and package.
Vowpal Wabbit 9.1.0 release notes

Resources