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.
Related
I want to install protobuf, but as soon as i input "./autogen.sh",it has the error like this:
aclocal: couldn't open `configure.in': No such file or directory
autoreconf: aclocal failed with exit status: 2
I have search for the answer for nearly one day.
I have tried to install many versions of protobuf ,but the error is still on , and i have tried to touch an empty file named "configure.in",it has been failed.so i will appreciate if someone can help me ,thanks very very much.
It sounds like your system has a very, very old version of autoconf installed. These days the input to autoconf is usually called configure.ac, and it has been that way for at least a decade, maybe longer. You could try renaming configure.ac to configure.in, but you'll probably run into other problems with such an old autoconf. I recommend updating autoconf to a newer version (and automake and libtool, too).
Alternatively, if you compile protobuf from a release package instead of from git, you can skip the autogen.sh step entirely, and go directly to running ./configure. It's usually better to use release versions anyway.
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
Currently used packages in my system are..
buildroot-2011.02
libpng-1.4.5
autoconf-2.65
python-2.7.1
I am trying to upgrade Libpng from version-1.4.5 to version-1.6.8.
But the newer version of Libpng requires Autoconf 2.68 or higher.
If I update Autoconf to 2.68, Python 2.7.1 fails which requires older version of Autoconf.
So I have to update Python to higher version which supports Autoconf 2.68.
But this is creating whole lot of problems for me because Python is used in many other modules which also fails to build.
Other solution I could think is keeping both versions of Autoconf i.e. 2.68 and 2.65
and I have to make sure Libpng uses Autoconf 2.68 and Python uses Autoconf 2.65.
Is it possible to do this? Is there any alternate solution to this problem?
Please try the newest Buildroot version and use BR2_EXTERNAL feature. This way you'll keep your own packages/configuration separately from BR tree. So you can update BR whenever you like and your stuff still will be working.
mkdir /home/user/my_bsp
cd /home/user/
git clone git://git.buildroot.net/buildroot
cd buildroot
make BR2_EXTERNAL=/home/user/my_bsp help
Now your BR tree will be looking for configuration and packages in /home/user/my_bsp
I have 3 programs, two of which require an older version of autoconf one of which requires a newer version. right now all three programs are calling the newest autoconf version. I believe I have to modify the path to autoconf in the makefiles of the first two programs to resolve the issue, but it could very well be aclocal.m4 or configure.ac for that matter.
Which file in gnu-make calls autoconf? Where and in what syntax is the path defined?
Nothing in make should have to call autoconf, unless (in some cases) you edit configure.ac. You execute autoconf yourself (either directly, or indirectly from autoreconf) to generate the configure script from configure.ac.
Some programs also include a script called autogen.sh or bootstrap that calls autoconf. This should only be needed when checking the program out from source control.
Note that if you just want to compile the program and you don't edit configure.ac, you don't even need to have autoconf installed.
My advice is, if you need to edit configure.ac, then manually call the required version of autoconf after you edit it. Or consider upgrading configure.ac to use the latest version. I'm sure the author of the original program will thank you for it.
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