I'm trying to install Qemu in Ubuntu 18.04 but I guess there is a problem with the Makefile.
./configure runs fine, but when i try to 'make' it, it exits with an error:
contrib/elf2dmp/download.c:9:10: fatal error: curl/curl.h: Arquivo ou diretório inexistente
#include <curl/curl.h>
^~~~~~~~~~~~~
compilation terminated.
/home/usr/Programas/qemu-4.1.0-rc1/rules.mak:69: recipe for target 'contrib/elf2dmp/download.o' failed
I would gladly accept some help to solve this, since I cannot figure it out. Thanks!
The compiler is looking for a system header file (provided by the libcurl library) which isn't present on your system. For Ubuntu 18.04 this should be in the libcurl4-gnutls-dev package, so if you install that and then do a 'make clean' and then repeat configure and make it ought to build OK.
In theory configure should have noticed that you don't have the curl library dev package installed and just disabled the parts of QEMU that require it. I suspect this is an upstream bug. I haven't been able to reproduce your setup, but I have a good guess about what the problem is, and I think this patch to QEMU should fix it:
https://patchew.org/QEMU/20190719100955.17180-1-peter.maydell#linaro.org/ -- so if you could test that that would be helpful.
NB: If your /etc/apt/sources.list has the correct deb-src lines in it, then you can use "apt build-dep qemu" to install all the -dev packages that would be needed to build the official Ubuntu QEMU. This might help you to avoid surprises in future where it turns out that the QEMU you've compiled yourself is missing some optional functionality because a -dev package wasn't present at compile time.
Related
I am trying to install OpenMPI on a new install of RHEL 9.1, and keep getting this error while using mock:
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.6QyYma (%build)
Macro expanded in comment on line 708: %{install_in_opt}, then we're instaling OMPI to
Bad exit status from /var/tmp/rpm-tmp.6QyYma (%build)
Full output here. Generated from $ mock -r rhel-9-x86_64 rebuild openmpi-4.1.4-1.src.rpm. Not sure if it changes things, but I did do $ mock -r rhel-9-x86_64 --init beforehand as well.
I got a src.rpm from the OpenMPI download page, and because I did not know how to install it, used this and this, as well as the epel docs to help me along the process. I changed any rhel or epel 7 references to 9, and during installation/initialization for mock, everything seemed to work alright (as far as I could tell).
Coming from Ubuntu, I previously used the deprecated mpif90 to compile mpi stuff, but I believe I was able to install that using a package. I now want to use mpifort. Is there a better/different way to install the mpifort compiler wrapper, or a problem with my installation process? Is it not supported currently, and should I install legacy support of some kind?
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.
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.
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?
I am trying to compile, libgphoto2 with libxml2 support followint the guidelines here. Everything is ok until I try to run ./configure:
./configure --prefix=/tmp/gphoto2/local --with-libxml2=yes
That appears to me as a correct syntax, however I got an output:
LIBXML2 to support Olympus ..: no
I have checked this in 2 different systems (LinuxMint 11 x64 and Ubuntu 13.04), and I have found the same problem.
Can anyone give me a clue or solution?
Is there any problem with the syntax?
Is there a common problem with the configure --with-PACKAGE[=yes] option?
Is there a common problem with LIBXML2 used in compilation?
Thanks for any help!
This problem as appears on Debian Wheezy (Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux) and the latest libgphoto2 release 2.5.2
libxml2-dev package is installed :-
Package: libxml2-dev
State: installed
Automatically installed: no
Multi-Arch: same
Version: 2.8.0+dfsg1-7+nmu1
Not totally familiar with configure scripts
but configure.ac file has line:-
AC_CHECK_HEADER(libxml/parser.h,[
which I assume looks for libmxl/parser.h
the libxml2-dev package delivers the file
/usr/include/libxml2/libxml/parser.h
It looks like libgphoto2 is designed for libxml2 library in a different place
Tried various solutions but only the following worked
as root I sym linked libxml2 to the place libgphoto2 was looking
ln -s /usr/include/libxml2/libxml /usr/include/libxml
After compiling libgphoto2 and gphoto2 this enabled gphoto2 to talk to my Olympus E-510
Bug raised on gphoto sourceforge site (https://sourceforge.net/p/gphoto/bugs/953/) and a patch fix has been provided
Just found another way. Thanks for your help.
After digging in the config.log file created after the ./configure tool, I found the libxml2 error (that I wrongly supposed to stop the configure script):
conftest.c:75:27: fatal error: libxml/parser.h: No such file or directory
But I knew it was there but can't find it! So I checked it and found it under
/usr/lib
And found somewhere else that libxml2 package comes with a script (xml2-config) to give library linking information and more so:
$ xml2-config --cflags
-I/usr/include/libxml2
And the just needed to add the output to the CFLAGS environment variable when configuring:
$ CFLAGS="-I/usr/include/libxml2" ./configure --prefix=/tmp/gphoto2/local --with-libxml2=yes
And everything else was just ok!
Usually, a --with-some-package=yes option checks for the existence of header files for some-package on your system. If it doesn't find the required header files, then it still outputs "no" to the terminal. Have you installed your distribution's libxml2-devel (or similarly named) package?