I am following the doc (http://mesos.apache.org/gettingstarted/) and trying to install Mesos on my mac. When I try to configure it, it gives me the error:
checking python extra linking flags... -u _PyMac_Error Python.framework/Versions/2.7/Python
checking consistency of all components of python development environment... no
configure: error: in `/Users/syang/Desktop/git/mesos/build':
configure: error:
Could not link test program to Python. Maybe the main Python library has been
installed in some non-standard library path. If so, pass it to configure,
via the LDFLAGS environment variable.
Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
============================================================================
ERROR!
You probably have to install the development version of the Python package
for your distribution. The exact name of this package varies among them.
============================================================================
I use Python 2.7.8 and I am trying to install Mesos 0.23.0. I did some search, it looks like after installing command tools using xcode, the linking problem should get handled. However, it doesn't look like that to me. Is there anyone who has similar experience and can help me?
Thank you.
The easiest way of running Mesos on local machine is to use https://github.com/bobrik/mesos-compose (Docker) or https://github.com/mesosphere/playa-mesos (Vagrant)
There are a bit different when build it in OSX. You could use "brew install mesos" to install it directly. https://github.com/Homebrew/homebrew/tree/master/Library/Formula/mesos.rb also show how to build mesos in osx.
I dont know if you have resolved this issue but for future reference I would like to suggest the below steps based on this blog http://gwikis.blogspot.com/2015/08/building-mesos-0230-on-os-x-yosemite.html
$ cd mesos-0.x./build/
$ PYTHON=/usr/bin/python ../configure
Moreover in case that you receive any errors like libapr-1 is required for mesos to build. or libsubversion-1 is required for mesos to build. then you could do the following, assuming that apr and subversion libs are installed with brew.
$ PYTHON=/usr/bin/python ../configure -with-svn=/usr/local/Cellar/subversion/1.8.13/ -with-apr=/usr/local/Cellar/apr/1.5.2/libexec/
To verify why the Python path is not correct and the compile fails in the first place please go once through the blogpost.
Related
is there a way to install rstan on a Gentoo amd64 system? rstan depends on v8-r (https://cran.r-project.org/web/packages/V8/index.html), which depends on a v8 installation. I haven't found a working v8 ebuild, v8 failed to compile with didactic-duck ebuilds. I also tried nodejs, without success. Compiling v8 from source failed with "unsupported linux distro".
Thanks, Sven
UPDATE: as of the latest version of V8 you can use:
# For Linux: download libv8 during installation
Sys.setenv(DOWNLOAD_STATIC_LIBV8=1)
install.packages("V8")
This way, you can install the V8 package on any x64 Linux system, without separate system requirements. See also this post: https://ropensci.org/technotes/2020/11/12/installing-v8/
Original answer
The R package V8 simply needs libv8 headers and shared library. The best solution is to use the V8 engine from NodeJS, but this can only be done if NodeJS itself was built with the --shared option. I don't use Gentoo myself, but from the above I guess this is currently not the case.
You have to talk to the maintainer of the nodejs package in Gentoo, and ask them to enable shared libnode. Below some references about this from Fedora and Debian, that might get you started:
Fedora: https://src.fedoraproject.org/rpms/nodejs/pull-request/4 and https://src.fedoraproject.org/rpms/R-V8
Debian: https://packages.debian.org/bullseye/libnode-dev and https://packages.debian.org/bullseye/r-cran-v8
If you can't get this to work, you could also build libv8 yourself, but I have to warn you this is pretty painful because upstream changes their API and build system every few weeks.
Some working examples are:
Homebrew: https://github.com/homebrew/homebrew-core/blob/master/Formula/v8.rb
Arch: https://aur.archlinux.org/packages/v8-r/
Same problem here.
I am afraid I don't have an answer myself. If it helps, the furthest that I have gone is to install "nodejs" and then manually try to install V8 from source:
R CMD INSTALL --configure-vars='INCLUDE_DIR=/usr/include/node/deps/v8/include LIB_DIR=/usr/include/node/libplatform' V8_3.2.0.tar.gz
But CRAN complains about "cannot find -lv8_libplatform", and with other combinations of INCLUDE_DIR and LIB_DIR I have not succeeded.
I have also tried several ebuilds from didactic-duck and even one from petkovich.
Also, installing from source seems to be impossible.
What "nodejs" install is the following, in case someone else has an idea about how to combine INCLUDE_DIR and LIB_DIR, or at least to enlight whether with nodejs is enough, or a full v8 installation is needed:
/usr/include/node/v8-fast-api-calls.h
/usr/include/node/v8-internal.h
/usr/include/node/v8-platform.h
/usr/include/node/v8-profiler.h
/usr/include/node/v8-util.h
/usr/include/node/v8-value-serializer-version.h
/usr/include/node/v8-version-string.h
/usr/include/node/v8-version.h
/usr/include/node/v8-wasm-trap-handler-posix.h
/usr/include/node/v8-wasm-trap-handler-win.h
/usr/include/node/v8.h
/usr/include/node/v8config.h
/usr/include/node/deps/v8
/usr/include/node/deps/v8/include
/usr/include/node/libplatform/v8-tracing.h
Thank you very much.
I'm trying to compile the libxkbcommon library for kodi for my Raspberry Pi 2.
The host machine is a dedicated Server running Ubuntu 16.04 x64.
Now there are two errors when I'm trying to compile libxkbcommon, depending on what yacc I'm using:
byacc:
YACC src/xkbcomp/parser.c
yacc: e - line 219 of
"/opt/kodi/xbmc/tools/depends/target/libxkbcommon/raspberry-pi2-release/src/xkbcomp/parser.y", syntax error
%destructor { FreeStmt((ParseCommon *) $$); }
^
Makefile:1637: recipe for target 'src/xkbcomp/parser.c' failed
btyacc:
parser.y:85: syntax error
Here is the source code of libxkbcommon:
https://github.com/xkbcommon/libxkbcommon
The xbcomp/parser.y file requires a number of (very useful) bison extensions, so it can't be processed by all yacc variants.
btyacc does not support bison-compatible pure-parser declarations. (It has a different, not entirely compatible mechanism which implements the same feature.) So it fails on the first instance of one of those declarations.
It should be possible to use byacc, but not the version which is available in the Ubuntu package repository. Although the Ubuntu package repository change history seems to suggest that the intention was to include the build option which allows %destructor, the actual binary currently available in the byacc repository was built without that option. (It is also several years old, and I think it would be useful to use a more recent version.) I reported this as launchpad bug 1776270, along with a suggestion for a possible fix.
I'm sure you'll be able to build the software using Gnu bison, which is available as the Ubuntu package bison. Since that's the most popular yacc version installed on developer machines, a failure to build with bison would probably have been noticed long ago.
If you would prefer to use byacc, for whatever reason, you'll have to download and build it yourself. You can get the most recent version from Thomas Dickey's byacc page, and then build it with the usual procedure: untar, configure, make, make install. When I tested this, I used the following configure line:
./configure --enable-btyacc --program-prefix=b --prefix=/usr
Only the first option is mandatory
* --program-prefix=b Install it as `byacc` rather than `yacc`
* --enable-btyacc Necessary for %destructor support
* --prefix=/usr Install it in /usr/bin and /usr/man. The default
is /usr/local/bin and /usr/local/man, which failed on
my Ubuntu install because of a missing -D option in the
install command in the Makefile.
I am trying to install guile locally on a system. It requires gnu/libtool. While installing all its dependencies, the "make check" command showed errors while installing gnu/libtool. But if I omitted the command and simply ran "make" followed by "make install", then it was able to install successfully. I was able to install the rest of the dependencies without any problem. However, when I run the following command, then I am getting the below mentioned error:
Command:
../configure --with-libltdl-prefix=$PREFIX/libtool --with-libgmp-prefix=$PREFIX/gmp --with-libunistring-prefix=$PREFIX/libunistring --with-libiconv-prefix=$PREFIX/libiconv --with-libreadline-prefix=$PREFIX/libreadline --with-libintl-prefix=$PREFIX/gettext --prefix=$PREFIX/guile
Error:
configure: error: GNU libltdl (Libtool) not found, see README.
the $PREFIX is defined and I have installed the libltdl library in the libtool folder. When I look through the include and lib sub directories of the libtool folder, I can find the libltdl folders and .so files.
So, I am unsure as to why the configure script is not able to find the locally installed version of libtool. I will be highly grateful if someone can point out the problem in the command and how to remedy this error.
I had a similar issue when trying to compile bind9 using distcc under Rasbian. I had previously installed the package libtool but I was also missing the package libtool-bin.
That solved my issue.
Try
apt list libtool* --installed
and see if both show up.
Edit as of ZMQ version 4.1:
Configure automatically looks for libsodium, so this is no longer required. If for some reason you wish to build it WITHOUT libsodium and you have it built and installed, configure libzmq with '--without-libsodium'.
So I'm having problems building/making zeromq with libsodium.
im using msys2 as the shell - specifically the mingw32_shell - , and zmq 4.1.0 rc1 with libsodium 1.0.1 and mingw-w64 32bit (gcc 4.9.2).
im currently able to compile libsodium like this
cd .../libsodium
bash configure
make
make check
make install
and everything is fine, all the tests pass and the libs and includes end up in the /usr/local/ folders that msys2 seems to know about.
then when i try to build zeromq with these commands
cd .../zeromq
bash configure --with-libsodium
make
make check
make install
i never get past the configure stage, as configure returns
checking for sodium_init in -lsodium... no
configure: error: libsodium is not installed. Install it or don't pass --with-libsodium to configure script
i have tried the methods suggested in this post - ZeroMQ doesn't spot libsodium - but to no success.
therefore my question is thus: how do i either set the locations for zeromq's configure to look for libsodium to spot, whether with --with-libsodium, --with-libsodium-include-dir= and --with-libsodium-lib-dir=, or have them 'installed' in a location that msys2's shell is able to find?
I assume you tried it already since the link you provided mentions it:
--with-libsodium=/usr/local
I tried this and it worked for me. However, I don't recommend this because for MSYS2, it is cleaner if /usr/local is used only for MSYS2 software, and not MinGW-w64 software. For MinGW-w64 i686 software, the 'right' prefix for 'local' is /mingw32/local
I've just now added libsodium as a dependency on the zeromq package.
Github MinGW-w64 zeromq PKGBUILD commit e32ae0
I will ask Alexey to rebuild and repackage it tomorrow.
When attempting to compile RNNLib, I got an error in NetcdfDataset.hpp:26:24 saying that Netcdfcpp.h could not be found. I looked around and found a bug report from 2011 that suggested that this was a bug, but it claimed to have been fixed. I have tried everything I can think of, including rebuilding NetCDF (a dependency of RNNLib) with various different flags, and have been unable to fix this bug. Can anyone give me a hand?
I had some trouble on a virtual machine building rnnlib.
I had to install the C and C++ version of NetCDF to get it to work.
The C version can be installed via sudo apt-get install libnetcdf-dev
I had to install the C++ version by building it.
Hope it will help. It's quite a difficult lib to install.
Maybe this helps someone: you can avoid some of the pain by installing packages from APT, and access the correct version mentioned by user3620756, which contains the netcdfcpp.h header file
. This happens through a legacy package, available on Ubuntun 16.04 (Xenial universe, see APT repository).
First install libnetcdf for C, then install libnetcdf-cxx-legacy-dev which should depend on libnetcdf-c++4 and install required C++ libraries on the go:
sudo apt install libnetcdf-dev libnetcdf-cxx-legacy-dev
The newest version doesn't have this netcdfcpp.h file anymore.
I had to use ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-cxx-4.2.tar.gz to get it working.
I have also followed the same process and it worked for me
"The newest version doesn't have this netcdfcpp.h file anymore. I had to use ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-cxx-4.2.tar.gz to get it working."
After downloading the folder, I had to build it by entering into the netcdf folder. I used simple command for the task :
.\configure
make
sudo make install
But in the file named as "NetcdfDataset.hpp", I have to give the complete path of the netcdfcpp.h file. For my case the path of the include file is :
#include "/Volumes/Macintosh_HD_2/WordSpottingProj/trunk/CODE C++/rnnlib_source_forge_version/netcdf-cxx-4.2/cxx/netcdfcpp.h"
I had this problem in the context of trying to use a makefile that called for netcdfcpp.h:
$ make -f makefile_MAC
c++ -O2 -o burn7.x burn7.cpp -I/opt/local/include -L/opt/local/lib -lm -lnetcdf_c++
burn7.cpp:31:10: fatal error: 'netcdfcpp.h' file not found
#include <netcdfcpp.h>
^
1 error generated.
make: *** [burn7.x] Error 1
I'm on a Mac, so I used Homewbrew to install the NetCDF package, but version 4.3.3.1 didn't appear to have netcdfcpp.h:
brew install homebrew/science/netcdf
However, I found that installing it with an additional flag resulted in this version being included:
brew install homebrew/science/netcdf --with-cxx-compat
I assume that the same is true of other installation/compilation methods, and not that this file has been taken out of versions since 4.2 as others answers state. Maybe it was a default option before and now it isn't?