I'm trying to install ncurses to a non system-wide prefix (for cross compilation).
Everything worked fine and I was able to install ncurses to the specified prefix, with the header files residing in <prefix>/include/ncurses.
A program I'm trying to compile (specifically GHC) doesn't find the headers, because it tries to #include <ncurses.h>, which doesn't work. (include <ncurses/ncurses.h> does work though, but GHC doesn't try this.)
So I thought installing the headers to <prefix>/include directly would do the trick, but I wasn't able to this. Passing --includedir=<prefix>/include to the configure script of ncurses didn't give the desired result, because the installed ncurses.h then tries to #include <include/ncurses_dll.h>, which doesn't work.
<prefix>/include is of course in the search path of the used CPP.
As a rule, --includedir for autoconf-based configure scripts is used to tell the makefiles where to install header files, not where to include them from during compilation.
Instead, the options that you might want to set would be in the CPPFLAGS variable. For instance, since GHC expects the ncurses header files only in the standard location, you might work around the problem by specifying both of the directories as -I options in CPPFLAGS.
Here are a few discussions to help:
4.8.1 Preset Output Variables (autoconf manual)
how to set include paths with autotools
With autoconf/automake, how do I specify include file paths?
What is the difference between DEFS and CPPFLAGS in autoconf and automake
By the way, that prefix/lib looks odd...
Regarding the comment about --disable-overwrite, Linux and some other platforms default to enabling this feature. OSX for one does not. At the end of configuring, the configure script runs a makefile rule to show the resulting configuration. If overwrite is disabled, you would see a message like this:
** Include-directory is not in a standard location
Related
A user of xnec2c was trying to build on OSX and had autoconf issues because PKG_CHECK_MODULES could not be found since MacPorts puts it in a funny spot.
The user made autoconf work like so:
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh
ACLOCAL_PATH=/opt/local/share/aclocal ./configure
I would like to make it build on OSX without special user path hacks for ACLOCAL_PATH. Can that be done?
I started writing a possible fix below and realized it could an xyproblem so posed the question just above. However, if this starts any gears turning, then I would be open to a bit of special-casing for OSX:
For example, would it be possible (if not advisable) to detect:
Is PKG_CHECK_MODULES missing?
If so:
is it OSX?
Is [ -d /opt/local/share/aclocal ] true?
Does the macro exist there?
While aclocal has a few ways of appending to its search path (see https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html), you cannot modify that macro search path using code in configure.ac:
When the shell code in configure is run, it is too late, as the available macros have already been expanded. When autoconf (is it autoconf or something else? anyway, m4 called from autoreconf) generates configure from configure.ac by having m4 expand the macros it is also too late: aclocal has already collected the m4 macros it could find.
So what you would need is a step before the autoreconf run - which is beyond what I would consider a buildsystem needs to do.
What you can do: Put static strings into the top level Makefile.am file like e.g.
ACLOCAL_AMFLAGS = -I auto-m4 -I project-m4 -I /opt/local/share/aclocal
(this example uses auto-m4/ with AC_CONFIG_MACRO_DIR([auto-m4]) for the *.m4 files automatically put there by autoreconf/autopoint/libtoolize and project-m4/ for the project specific *.m4 files).
Of course, you should already have
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
before invoking PKG_CHECK_MODULES for the first time so that the problem of the missing *.m4 file will be detected at the earliest possible time, i.e. when autoconf is about to generate a configure file with PKG_CHECK_MODULES unexpanded.
You could use some m4 code to print a lengthy error message if PKG_CHECK_MODULES is not defined. Something along the lines of (untested)
m4_ifndef([PKG_CHECK_MODULES], [dnl
m4_fatal([Could not find the PKG_CHECK_MODULES macro. Check that the pkg.m4 file is available and aclocal finds it (e.g. set ACLOCAL_PATH=/opt/local/share/aclocal).
])dnl
PKG_CHECK_MODULES([FOO], [foo])
Personally, I would go with m4_pattern_forbid and make sure OSX builds with homebrew work OOTB, and then document idiosyncrasies for building on rare and buggy systems like OSX with macports or SunOS without GNU tools in the INSTALL file.
Isn't it a bug in macports/OSX that aclocal there cannot find its *.m4 files? Shouldn't there be a dirlist file pointing to /opt/local/share/aclocal? Or perhaps they macports users should have an aclocal in their PATH which actually finds the macports macro files?
In any case, I would not consider it my build systems's job to fix a buggy system. You need to draw the line somewhere.
This question may not make much sense if my understanding of both the pkg-config and environment modules is somewhat incorrect, but I'll ask anyways as I could not find anything specific on this topic. There might be an entirely better solution available, if that is the case, I am all ears!
I while back I started using modules to easily load my development environment as needed (i.e. using commands like module load foo etc.). More recently, I have adopted the meson build system for my projects. In meson, libraries are treated as dependencies, which are found using pkg-config in the background instead. So now I have two ways of discovering libraries and setting up their lib and include directory.
As an example, I have the following (simplified) module script for library foo (I am using lmod which is based on lua):
prepend_path("LD_LIBRARY_PATH", "/opt/foo/lib")
prepend_path("CPATH", "/opt/foo/include")
I could also have a pkg-config file (*.pc) doing something similar like (that is, if my understanding of pkg-config is correct)
prefix=/opt/foo
includedir=${prefix}/include
libdir=${exec_prefix}/lib
Name: foo
Cflags: -I${includedir}
Libs: -L${libdir} -lfoo
Now both seem to be doing pretty much the same thing (in terms of setting up my environment), but simply using modulefiles will not allow meson to find my dependencies and I still have to use pkg-config (which requires basically creating two files, either manually or dynamically, but that sounds like a maintenance burden and also not very clean). Equally, I could create the pkg-config file and add the location of that file into the PKG_CONFIG_PATH, i.e. something like
prepend_path("LD_LIBRARY_PATH", "/opt/foo/lib")
prepend_path("CPATH", "/opt/foo/include")
prepend_path("PKG_CONFIG_PATH", /path/to/*.pc/file)
but again this requires two files (pkg and module). I rather like the module environment and so don't want to ditch that, so is there a better / cleaner way of doing things, where I just load a module file which will allow pkg-config (and thus meson in turn) to know about the dependency?
As of today, there is no bridge between the environment module and the pkg-config tools. The best thing I think that could be achieved to keep the module system, is to have a script that queries every pkg-config files available and create the corresponding modulefile. And run that script regularly to keep things in sync.
I want to install Libav locally in a folder and for that I have to install yasm (I can disable the dependency but I don't want to just for the sake of the argument). The installation of the package is done in the terminal via "./configure" and "make" (when I run "./configure" I receive the message, that yasm is missing). How can I tell to "./configure" to take it's yasm dependencies from the path "./libs" (there is a folder with libraries in the parent folder). Should I modify the makefile (and if yes should I change only the LDflags? to what?) or add the " --extra-ldflags="-L./libs" " to the ./configure command? What would be the use of cflags here?
To have autotools' configure use dependencies from a specific directory, the following may or may not work, as the configure script can be written differently:
--extra-ldflags (there should be --extra-cflags too) is fine, if it's there;
for library dependencies, you can add CFLAGS="-I<path>" CXXFLAGS="<same>" LDFLAGS="-L<path>" to ./configure's environment or to its command line arguments;
cleaner approach: if you have pkg-config configuration generated and installed for your dependencies, you can specify a PKG_CONFIG_PATH instead. In special cases of cross-compilation, one can use PKG_CONFIG_SYSROOT_DIR.
for local host executables, append/prepend to PATH.
Related question: https://unix.stackexchange.com/questions/19663/how-to-change-the-compiler-settings-with-automake
My linux environment is based off of a high compute cluster that does not allow users to install to /usr/bin/ or use sudo. I'm trying to use ./configure (made from protocol buffers) to install to my home. When configure searches for the CXX files it is not finding the compilers that are located in the bin because they are named things like 'g++34' instead of 'g++'. I want to point the configure file at this specific compiler, but can't seem to get the command right to do so. Again the directory where the compiler is gets searched, it is just named funny (using an alias hasn't worked either).
How do you use a arguments in a configure file to point at a specific compiler?
Just use:
./configure CC=gcc34 CXX=g++34
etc. If you have a really old version of configure you might have to do it via the environment instead:
CC=gcc34 CXX=g++34 ./configure
I am trying to build a library with a different build system, but files in the library require a config.h header file that is generated after running the configure scripts generated by autoconf.
This is the sequence of steps I am following to try and generate the config.h file that is needed
autoreconf -ivf
./configure --disable-dependency-tracking
The build system guarantees that the library gflags will be linked and the headers will be available at preprocessing time. But the configure script exits with the following error
configure: error: Please install google-gflags library
Is there some way I can get the list of required libraries (such as gflags) and then pass arguments to the configure script that tells it to assume that this library exists on the system? I went through the help output for both autoreconf and ./configure and wasn't able to figure this out.
Sorry for the long explanation and problem. I am very new to autoconf, etc.
The answer to your question is: no, it is not possible to get a list of dependencies from autotools.
Why?
Well, autotools doesn't track dependencies at all.
Instead, it checks whether specific features are present on the system (e.g. a given header-file; or a given library file).
Now a specific header file can come from a variety of sources, e.g. depending on your distribution the foo.h header can be installed via
libfoo-dev (Debian and derivatives)
foo-devel (Fedora)
foo (upstream)
...
In your specific case, the maintainers of your project output a nice error message telling you to install a given package by name.
The maintainers of your project also chose to abort with a fatal error if a given dependency is not available.
The reason might well be, that the project simply won't work without that dependency, and that is impossible to compile the program without it.
Example
Your project might be written in C++ and thus require a C++-compiler.
Obviously there is little use in passing some flags to ./configure so it assumes that there is a C++-compiler available if in reality there is none.
There is hope
However, not all is bad.
Your configure script might will have the ability to disable certain features (that appear to be hard requirements by default).
Just check ./configure --help and look for flags like
--enable-FOO
--disable-FOO
--with-BAR
--without-BAR
automation?
One thing to know about autotools, is that configure really is a program (the source-code being configure.ac) written in some arcane programming language (involving bash and m4),
This means that it can practically have any behavior, and there is no single standard way to achieve "dependecy tracking".
What you're trying to do will not work as umläute already said. On the other hand, depending on the package you're trying to build, you may be able to tell ./configure that a given library is there even if it isn't.
For instance if the script uses pkg-config to check for the presence of a library, you can use FOO_CFLAGS and FOO_LIBS to override the presence checking and telling it "yes those packages are there, you just don't know how to find them", but these are very package-specific so you may have to provide more information if that's what you're looking for.