I use the following autotool steps to install my pacakges:
./configure
make
make install prefix=/my/path
However I got the following libtool warning "libtool: warning: remember to run 'libtool --finish /usr/local/lib' and "libtool: warning: 'lib/my.la' has not been installed in '/usr/local/lib'" when using the autotool to install my software package. If I change to the following command, the problem disappear:
./configure
make prefix=/my/path
make install prefix=/my/path
It looks like the first method doesn't substitute the prefix correctly to libtool. How can I avoid this problem?
Among the information that libtool archives record about the libraries they describe is the expected installation location. That information is recorded when the library is created. You can then install to a different location, but libtool will complain. Often, libtool's warning is harmless.
In order to avoid such a warning, you need to tell libtool the same installation location at build time that you do at install time. You present one way to do that in the question, but if you're using a standard Autotools build system then it is better to specify the installation prefix to configure:
./configure --prefix=/my/path
make
make install
Alternatively, if you're installing into a staging area, such as for building an RPM, then use DESTDIR at install time. libtool will still warn, but you'll avoid messing up anything else:
./configure
make
make install DESTDIR=/staging/area
Related
I want to use the Google Logging Library (glog, https://github.com/google/glog) but it depends on the autoconf tools. How can I now disable the use of autoconf when I compile glog? Or maybe it is possible to use autoconf ONCE and then remove the dependency or disable autoconf for all following compilation runs. I just couldn't figure out how to do this...Can you help me?
Thanks!
I want to use the Google Logging Library (glog, https://github.com/google/glog) but it depends on the autoconf tools. How can I now disable the use of autoconf when I compile glog?
Probably not, if it depends on autotools.
Or maybe it is possible to use autoconf ONCE and then remove the dependency or disable autoconf for all following compilation runs.
Sure, there's a few ways of doing this. The easiest is: Use a package. The next easiest (if you need more up to date features) is grab a code snapshot and configure; make; make install to your own system which will install the libs/headers (in /usr/local/lib in this instance, which can be adjusted). If you don't want to do that, you can always relocate where libs/headers get installed: configure; make; make DESTDIR=/some/dir install. Then there's using packaging sources (and a code snapshot) and making your own package.
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.
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 install a rubygem which keeps on trying to read a library which is not available.
grep: /usr/lib64/libgdbm.la: No such file or directory
/bin/sed: can't read /usr/lib64/libgdbm.la: No such file or directory
libtool: link: /usr/lib64/libgdbm.la' is not a valid libtool archive
In order to work around this, I installed my own libgdbm and provided the path to the libgdbm in the makefile LDFLAGs but to no avail.
Any help is much appreciated.
This rubygem seems to do dirty stuff, since any clean library search (-L or pkg-config) would have resulted in a message like "library/package gdbm not found". And especially the grep-and-sed procedure on the la file seems really dirty. Make sure Santa knows that the author of this gem gets no presents this year.
The gem probably has the path to the libtool archive hardcoded. First of all, try to grep for /usr/lib64/libgdbm.la in the Makefile of the gem. Change the hardcoded path, and make sure the installation script has no write permissions on any system directories, because it seems to run wild with seds.
Libtool requires intimate knowledge of your compiler suite and operating system in order to be able to create shared libraries and link against them properly. When you install the libtool distribution, a system-specific libtool script is installed into your binary directory.
However, when you distribute libtool with your own packages, you do not always know the compiler suite and operating system that are used to compile your package.
For this reason, libtool must be configured before it can be used. This idea should be familiar to anybody who has used a GNU configure script. configure runs a number of tests for system features, then generates the Makefiles (and possibly a config.h header file), after which you can run make and build the package.
Libtool adds its own tests to your configure script in order to generate a libtool script for the installer's host machine. For this you can play with LT_INIT macro in configure.ac.
So in short, if your package has configure file, run it before running Make
make distclean //clean up all the previous generated files
autoconf //or autoreconf to generate configure script from configure.ac and configure.in
automake //to generate new Makefile.in from Makefile.ac
./configure //to generate new Makefile and libtool
I want to install Ruby SVM. I already have macports with normal settings, and installed libsvm via port just fine. But when I go to compile rubysvm, it barfs. :(
Ruby SVM: http://rubysvm.cilibrar.com/download/ (most links are 404 though)
libsvm: http://www.csie.ntu.edu.tw/~cjlin/libsvm/
Try this:
sudo port install libsvm
wget http://debian.cilibrar.com/debian/pool/main/libs/libsvm-ruby/libsvm-ruby_2.8.4.orig.tar.gz
tar -xzf libsvm-ruby_2.8.4.orig.tar.gz
cd libsvm-ruby-2.8.4
./configure
... and you get the error:
...
checking libsvm/svm.h usability... no
checking libsvm/svm.h presence... no
checking for libsvm/svm.h... no
Error, cannot find LIBSVM svm.h header.
I've tried this, without success:
export DYLD_LIBRARY_PATH=/opt/local/include/:/opt/local/lib/
(... ditto for C_INCLUDE_PATH, LD_LIBRARY_PATH, CPATH, & LIBRARY_PATH)
LDFLAGS="-I/opt/local/include -L/opt/local/lib" CPPFLAGS="-I/opt/local/include -L/opt/local/lib" ./configure
How do I fix this?
libsvm-ruby assumes libsvm installs its header in PREFIX/include/libsvm/svm.h, but the macports package puts it in /opt/local/include.
It's a kludge, but the easiest fix is to manually make the directory /opt/local/include/libsvm and move/copy the svm.h header there. You may still need to run your configure command with the LDFLAGS and CPPFLAGS settings since it looks like the macports install doesn't update pkg-config (which libsvm-ruby uses to try to find the compiler flags).
I'd report this as a package bug to the macports maintainer. If you understand macport's Portfiles, you can probably even provide a patch.
Update: I haven't actually tried this, so there may be other issues once you get past the header file detection.
Update 2: I was able to get past configure with:
sudo mkdir /opt/local/include/libsvm
sudo cp /opt/local/include/svm /opt/local/include/libsvm/
CPPFLAGS=-I/opt/local/include LIBS=-L/opt/local/lib ./configure
But libsvm-ruby appears to depend on obstack.h, which doesn't exist natively on OS X. Based on this, there might be a way to copy in the files that you need, but you'll need to patch the libsvm-ruby main.cpp and Makefile to link that in.
Good luck!