I am looking for something like DISTCHECK_CONFIGURE_FLAGS but more flexible.
I am using an external package in my program. Let's say foo and on my laptop it's installed to ${HOME}/soft/foo.
configuring with the autotools is simple:
./configure CPPFLAGS=-I${HOME}/soft/foo/include LDFLAGS=-L${HOME}/soft/foo/lib
but distcheck is giving me headaches. When distcheck unpacks and configures, how do I tell it to use my CPPFLAGS and LDFLAGS?
DISTCHECK_CONFIGURE_FLAGS is close, but incorrect: other maintainers might have the foo library installed under /opt/ or /software/random/whatever or /usr/local/foo-master and I don't want to impose my environment on other maintainers.
The answer is to not hard-code anything in the Makefile.am. Automake will inherit several environment variables from autoconf.
All one needs to do is pass the CPPFLAGS and LDFLAGS used to configure the package:
DISTCHECK_CONFIGURE_FLAGS = CPPFLAGS=${CPPFLAGS} CFLAGS=${CFLAGS}\
${CXXFLAGS}=${CXXFLAGS} LDFLAGS=${LDFLAGS}
and now 'make distcheck' will use the requested flags and find the headers and libraries for the desired package.
Related
I'm a real beginner at this, so apologies in advance for obvious questions. I'm trying to compile a custom build of ffmpeg that has some extra dependencies the normal build does not. Among those is libgcrypt and libgpg-error - I know this, because when I run configure, it fails, and the log contains:
C:/workspace/windows/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgcrypt
C:/workspace/windows/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgpg-error
With this in mind, I cloned the repo for libgpg-error, ran make and make install, which created libgpg-error.dll.a and libgpg-error.la in /home/myuser/w64root/lib. I've tried adding this path to my $LIB environment variable, but the configure run still says it can't find the library.
How can I make it visible? I also have pkg-config available on the machine - would manually creating a .pc file help me any?
Thanks!
If you run ./configure -h, you should see this in the output:
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
CXX C++ compiler command
CXXFLAGS C++ compiler flags
Note LDFLAGS in particular. That covers your case, since /home/myuser/w64root/lib
is not among the linker's standard search directories. Therefore run:
export LDFLAGS='-L/home/myuser/w64root/lib'; ./configure
and you should be OK.
I have a small project that requires a few standard libraries, say libpng and boost. For now I hope that project can build easily on any of my collaborators machines (OSX/Unix/Linux), but am not concerned packaging or installing it right now. My question is, is there an easy way to write "home-brewed" Makefile or configure file that can automatically find and use those libraries on a particular *nix system?
I know Autoconf and CMake are tools designed for such tasks, but I and my collaborators do not want to go into the fuss for such a small project, at least not right now.
Another possibility I have in mind is pkg-config. Is that a recommended approach? I currently have two problems with that: (1) it cannot find all libraries, (say boost, discussed here, here and here), and (2) not all system seems to have installed pkg-config.
The solution I hope to have ishave in mind is to write a Makefile that looks like below.
INCpng = $(shell command retrieves "-I/path/to/png.h")
LIBpng = $(shell command retrieves "-L/path/to/libpng.so -lpng")
INCboost = $(shell command retrieves "-I/path/to/boost")
LIBpng = $(shell command retrieves "-L/path/to/libboost.so -lboost")
SomeFile: SomeFile.cc
$(CXX) $(CXXFLAGS) $(INCpng) $(INCboost) $(LIBpng) $(LIBboost) -o $# $<
I'm also open to write a not-to-complicated configure file.
pkg-config was designed for more-or-less exactly this purpose. It was designed to replace the X-config scripts/etc. that many projects had been writing on their own before that.
I don't know about CMake but I believe the autotools are just using pkg-config internally.
For things that pkg-config cannot find (and that do not have their own X-config) the only thing you can do is use reasonable defaults and allow people to over-ride them (you could test some common alternatives as fallback defaults as well but you still need to allow user over-riding.
I'm trying to compile one library (xcrysden, based on Make file) which during its compilation execute ./configure of an external dependencies - Tk and Tcl 8.5 - and compiles them.
So, the structure is roughly like this:
The main Makefile:
...
cd external/src; make;
external dependencies (pre-)makefile (Tk):
include ../Make.sys
cd /unix
./configure
make
make install
Make.sys included by external makefile:
...
CFLAGS =...
CC =...
The configure, obviously, produces another makefile in /external/src/unix to be used by Tk.
In Tk documentation it is written:
If you wish to specify a particular compiler, set the CC environment variable before calling configure. You can also specify CFLAGS prior to configure and they will be used during compilation.
But from the resulting Makefile i definitely see that neither the defined compiler (CC) nor flags (CFLAGS) are used. Does it qualify as 'environment variable' when it is set in another make file?
I actually have problems compiling Tk, so i try to pass not only compiler but linking info
LDFLAGS = -L/opt/local/lib -lfontconfig .
I want to do it in a neat way (that is, modifying only Make.sys of the library dependent on Tk). But then i face the problem that not only don't i know how to pass LDFLAGS to Tk configure, but even CC/CFLAGS are not there. I'm not sure if this is specific to particular library (Tk) using ./configure or I misunderstand the general usage of ./configure.
p/s/ i'm compiling on OS-X using gnu compilers.
The problem is that the variables you define in ../Make.sys are currently local to the shell that processes the include; the configure and make are run in subprocesses and don't find out that you've got any preferences. The right thing to do is to add:
export CFLAGS CC
between the include and the call to ./configure.
You could also put it inside Make.sys, or invoke configure as CFLAGS=$CFLAGS CC=$CC ./configure. You probably shouldn't set the values directly in the invocation of make though; setting the compiler can mean that different other flags are required as well.
IF(UNIX)
# CROSS COMPILATION! ON/OFF
#SET(CMAKE_C_COMPILER /home/username/projects/buildroot/output/host/usr/bin/arm-linux-gcc)
#SET(CMAKE_CXX_COMPILER /home/username/projects/buildroot/output/host/usr/bin/arm-linux-g++)
#SET(CMAKE_C_COMPILER /home/username/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-eabi-gcc)
#SET(CMAKE_CXX_COMPILER /home/username/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-eabi-g++)
here is what I do now for cross-compilation. I want to add option to run it alike that:
make CROSS_COMPILE=~/projects/buildroot/output/host/usr/bin/arm-linux-
and if I do not path CROSS_COMPILE to make (not to cmake) it must use system defaults so cmake must path this option to makefile. How can I make it?
Buildroot generates a CMake toolchain file for you. Depending on your Buildroot, it might be directly in the output directory, or in output/host/usr/share/buildroot. The file is named toolchainfile.cmake. Then to build your CMake applications, do:
cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/buildroot/output/host/usr/share/buildroot/toolchainfile.cmake
This file contains all the definitions of the cross-compiler paths, pkg-config environment variables, headers and libraries location, etc.
For the simplest method, do this:
SET(CMAKE_C_COMPILER $(CROSS_COMPILE)gcc)
SET(CMAKE_CXX_COMPILER $(CROSS_COMPILE)g++)
When the CROSS_COMPILE variable is passed to make, it will be substituted with the cross compiler path.
Now, the proper way. Ideally, the CROSS_COMPILE variable should be defined when CMake is run as it is meant to be cross-platform. Using the first solution could break if other CMake generators are used.
This can be done as:
IF(UNIX)
SET(CMAKE_C_COMPILER ${CROSS_COMPILE}gcc)
SET(CMAKE_CXX_COMPILER ${CROSS_COMPILE}g++)
Then define the variable:
cmake -G "Unix Makefiles" -DCROSS_COMPILE=~/projects/buildroot/output/host/usr/bin/arm-linux-
In this case, CMake will generate proper build files, based on whether CROSS_COMPILE is defined or not.
While making a project with Makefile, I get this error:
error: implicit declaration of function ‘fatal’ [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
The ./configure --help shows:
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--disable-dependency-tracking speeds up one-time build
--enable-dependency-tracking do not reject slow dependency extractors
--disable-gtktest do not try to compile and run a test GTK+ program
--enable-debug Turn on debugging
How can I tell configure not to include -Werror?
Werror is a GCC argument, and you cannot remove it directly via ./configure. Otherwise, an option like --disable-error would show up in the help text. However, it's possible.
Set an environment variable:
export CFLAGS="-Wno-error"
That's for C compilers. If the project uses C++, do:
export CXXFLAGS="-Wno-error"
In the very rare case the project does not honor this variables, your last resort is to edit the configure.ac file and search for -Werror and remove it from the string it occurs in (be careful though).
It seems like the feature has been in autotools for many years:
./configure --disable-werror
Unfortunately, I wasn't able to get the following specific case to work:
./configure --enable-wno-error=unused-value
Maybe it could work if one escaped the '=' symbol, assuming it's possible. Like skim says, one can still use CFLAGS or CXXFLAGS.
I had to use --disable-Werror (with an uppercase W) on my module. While sudoman's answer above suggests to use --disable-werror (with a lowercase w).
It may look like a typo, but it is actually dependent on your particular configure setup, especially if configure is generated by autoconf. What needs to be passed to the configure script to disable Werror depends on how the build system was setup.
If your project uses the AX_COMPILER_FLAGS option from the autoconf-archive project, then by default -Werror is enabled.
In another module you may find something like this:
+AC_ARG_ENABLE([werror],
+ AC_HELP_STRING([--disable-werror],
+ [do not build with -Werror]),
And thus you would need to use --disable-werror.
This works for me, compiling curlpp on Lubuntu 16.10:
./configure --disable-ewarning
I ran into this problem, and it turned out that GCC was not installed on my freshly-started EC2 instance running Ubuntu 20.04 (Focal Fossa).
Simply running sudo apt install gcc fixed this issue for me.