I have a problem: I need to change the variable link_all_deplibs to 'no' in my libtool script. However my attempts to use _LT_AC_TAGVAR failed. Of course I can hack the libtool script after I run configure, but... It would be nice if I could do it in the way intended by autotools authors. Here is a sample configure.ac I used to test the feature:
AC_PREREQ(2.61)
AC_INIT([TEST_PROJ],[3.6],[a.a.godin#gmail.com])
dnl end versions
dnl project general settings
AC_CONFIG_AUX_DIR([.])
AC_CONFIG_MACRO_DIR([m4])
AC_CANONICAL_TARGET
AC_CANONICAL_HOST
AC_CANONICAL_BUILD
AC_PROG_CC_C99
AC_PROG_CXX
AM_INIT_AUTOMAKE(TEST_PROJ, 3.6, foreign)
AC_PROG_LIBTOOL
_LT_AC_TAGVAR(link_all_deplibs,CXX)=no
_LT_AC_TAGVAR(link_all_deplibs,)=no
LT_INIT
AC_CONFIG_FILES(Makefile)
AC_OUTPUT
Your help is much appreciated. Thanks in advance.
P.S.Do not merge it with --as-needed question. I've explained why this is a different question in a comment
Related
Trying to follow this tutorial I have done my own "Hello World" in c++.
This is the code prueba.cpp:
#include <iostream>
int main()
{
std::cout<<"Hola Mundo"<<std::endl;
return 0;
}
Then, I have created configure.ac file with this information:
AC_INIT([holamundo], [0.1], [address#address.com])
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
and Makefile.am
AUTOMAKE_OPTIONS = foreign
bin_PROGRAMS = holamundo
holamundo_SOURCES = ./prueba.cpp
Those files are in the same folder of prueba.cpp
Finnally, in console and in the same folder of prueba.cpp I run the commands:
aclocal (no errors)
autoconf (no errors)
automake --add-missing Then I have the next errors:
Makefile.am:3: warning: source file './prueba.cpp' is in a subdirectory,
Makefile.am:3: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least one source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However, this
automake: behavior may change in a future Automake major version, with object
automake: files being placed in the same subdirectory as the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
/usr/share/automake-1.16/am/depend2.am: error: am__fastdepCXX does not appear in AM_CONDITIONAL
/usr/share/automake-1.16/am/depend2.am: The usual way to define 'am__fastdepCXX' is to add 'AC_PROG_CXX'
/usr/share/automake-1.16/am/depend2.am: to 'configure.ac' and run 'aclocal' and 'autoconf' again
Makefile.am: error: C++ source seen but 'CXX' is undefined
Makefile.am: The usual way to define 'CXX' is to add 'AC_PROG_CXX'
Makefile.am: to 'configure.ac' and run 'autoconf' again.
Issue 1
Makefile.am:3: warning: source file './prueba.cpp' is in a subdirectory,
Makefile.am:3: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
[...]
Do not prefix source names with ./ (or ../) in Makefile.am.
Automake can handle sources and targets in bona fide subdirectories, with or without recursive make, but you do need to set up your project for that, and I would not go there until you have a better handle on Autotools basics.
Issue 2
Makefile.am: error: C++ source seen but 'CXX' is undefined
Makefile.am: The usual way to define 'CXX' is to add 'AC_PROG_CXX'
Makefile.am: to 'configure.ac' and run 'autoconf' again.
The diagnostic already explains the problem and the solution, but see also below.
Issue 3
/usr/share/automake-1.16/am/depend2.am: error: am__fastdepCXX does not appear in AM_CONDITIONAL
/usr/share/automake-1.16/am/depend2.am: The usual way to define 'am__fastdepCXX' is to add 'AC_PROG_CXX'
/usr/share/automake-1.16/am/depend2.am: to 'configure.ac' and run 'aclocal' and 'autoconf' again
Again, the diagnostic already describes a solution. Since it is the same solution that another diagnostic suggests, and that seems plausible and appropriate, that seems to be a pretty good bet. Specifically:
configure.ac
AC_INIT([holamundo], [0.1], [address#address.com])
AM_INIT_AUTOMAKE
AC_PROG_CC
# Configure the C++ compiler:
AC_PROG_CXX
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
Issue 4
Finnally, in console and in the same folder of prueba.cpp I run the commands:
Generally speaking, you should not manually run the individual autotools (autoconf, automake, etc.). Instead, use autoreconf, which will identify which of the (other) autotools need to be run, and will run them in the correct order. Among the command-line options it supports are -i / --install and -f / --force, which will provide for installing the local autotool components in the source tree. You should probably run autoreconf --install --force once in your source tree. After that, you should need only plain autoreconf, unless you change to a different version of the autotools or modify one of the local autotool components.
I'm trying to install the HDF4 library for GDAL using Cygwin, and the readme instructs me to configure the source code as such:
./configure <--disable-fortran>
--enable-hdf4-xdr
--with-zlib=/path_to_ZLIB_install_directory
--with-jpeg=/path_to_JPEG_install_directory
<--with-szlib=/path_to_SZIP_install_directory>
--prefix=/path_to_HDF4_install_directory
However, I can't seem to get the <--disable-fortran> part right. It returns an error when executed:
-bash: --disable-fortran: No such file or directory
What am I doing wrong? I'm a novice to programming.
Edit:
This is the link to the readme: https://support.hdfgroup.org/ftp/HDF/HDF_Current/src/unpacked/release_notes/INSTALL_CYGWIN.txt
as Dennis wrote, you are misunderstanding the meaning of <..> . In this context
they are optional not mandatory configuration
./configure <--disable-fortran>
--enable-hdf4-xdr
--with-zlib=/path_to_ZLIB_install_directory
--with-jpeg=/path_to_JPEG_install_directory
<--with-szlib=/path_to_SZIP_install_directory>
--prefix=/path_to_HDF4_install_directory
so one possible way is to include the first and not the second:
./configure --disable-fortran
--enable-hdf4-xdr
--with-zlib=/path_to_ZLIB_install_directory
--with-jpeg=/path_to_JPEG_install_directory
--prefix=/path_to_HDF4_install_directory
I know there is exist option for C to check the existing libraries using conf.CheckLib .
env=Environment()
conf=Configure(env)
if not conf.CheckLib('lapack'):
print 'Did not find Lapack, exiting!'
Exit(1)
How do I modify it for Fortran libraries
You have to roll your own CheckFortranLib(), based on the actual definition of CheckLib() in the source files SConf.py and Conftest.py.
If you succeed in this, please consider contributing your code to the SCons contrib repo. It would help the SCons project a lot.
I am trying to complete the installation for some software. According to which I have to add path. I am not getting it how to do that. Please guide me how to do the following steps.
Add the path to Rpa/Tk headers:
-I/usr/include/rpatk
To link to the Rpa/Tk libraries on Linux add the following link options:
-lrpa -lrvm -lrex -lrlib -lm
RVM library uses some math functions from the system math library, that is why you must include '-lm' to include the math library to your project in addition to the Rpa/Tk built libraries:
librpa librex librvm librlib
http://www.rpasearch.com/rpatk/doc/doxygen/rpadoc/html/rpatk_build.html
this will be within your configure script -- you will need to hack this and add the paths to where gcc/cc gets called
give the link to the actual tar.gz
looking at the example code: http://www.rpasearch.com/rpatk/doc/doxygen/rpadoc/html/js-tokenizer_8c-example.html
gcc -I/usr/include/rpatk -o js-tokenizer js-tokenizer.c -lrex -lrlib
so in short :
export LD_LIBRARY_PATH=/usr/include/rpatk:/usr/local/lib:/lib:/usr/lib
then running the configure may fix the issue
where the bit in bold would the path to the includes for this project
I am not sure exactly what my question is as I get seriously turned around by autoconf/automake/libtoolize etc. Several of us are trying to autoconferize mbsystem. I've thrown a repo up of the work to date here:
https://bitbucket.org/schwehr/mbsystem
I'm trying to improve the netcdf setup to use nc-config, but am uncertain how to do this correctly. I am working on configure.in. It seems unable to find a header with AC_CHECK_HEADER("netcdfcpp.h") after INCLUDES="$INCLUDES ``$nc_config --cflags``" (pardon the incorrect back ticks) as taken from the gdl netcdf check. What is the correct way to update the path from nc-config --cflags?
http://gnudatalanguage.cvs.sourceforge.net/viewvc/gnudatalanguage/gdl/configure.in?revision=1.121
I then tried to use AX_PATH_GENERIC and get stuck on this error with m4_include([m4/ax_path_generic.m4])
Running autoconf ...
configure.in:29: error: possibly undefined macro: AC_SUBST
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:12992: error: possibly undefined macro: AC_MSG_RESULT
Any help in getting better at creating a netcdf check that actually will work with funky non-standard install locations via nc-config and figuring out how to properly put a macro in the m4 directory would be a huge help.
A pointer to a package doing this really cleanly would be a super help. I've been looking at the netcdf, gdal, geos and gdl sources for examples. And things like the octopus netcdf check do not use nc-config... http://www.tddft.org/trac/octopus/browser/trunk/m4/netcdf.m4
The current setup with fink for netcdf 4.x:
nc-config --cflags --libs
-I/sw/opt/netcdf7/include -I/sw/include
-L/sw/opt/netcdf7/lib -lnetcdf
Thanks!
See Makefile.am: How to use curl-config and xml2-config in configure.ac? and substitute xml2/curl by netcdf.
Just use
PKG_CHECK_MODULES([libnetcdf], [netcdf])
in configure.ac, and then, in Makefile.am:
AM_CPPFLAGS = ${libnetcdf_CFLAGS}
bin_PROGRAMS = foo
foo_SOURCES = ...
foo_LDADD = ${libnetcdf_LIBS}
The "correct" way to use a third party m4 macro is to use aclocal (usually via automake) to generate aclocal.m4. If you are using automake, just add
ACLOCAL_AMFLAGS = -I m4
to Makefile.am and put
AC_CONFIG_MACRO_DIR([m4])
in configure.ac (after renaming configure.in).
If you are not using automake, add '-I m4' when you invoke aclocal. If you are not using aclocal, then you'll have to append the definition of the macro to the end of aclocal.m4 (and be careful to never run aclocal, as that will overwrite the file.)
There is no good example of a clean way to use conf scripts to do a build because using such scripts is an inherently flawed approach. A slightly cleaner approach is to stop using custom scripts and use pkg-config via PKG_CHECK_MODULES, but the cleanest way to do this is to educate your users. If the user wants to install the library in funky non-standard locations then they need to be educated enough to set LDFLAGS and CPPFLAGS appropriately.