UPDATE: First problem solved, second one described at the bottom of this post.
UPDATE2: Second problem solved as well.
I'm trying to learn about setting up GNU build tools (autoconf/automake) for a very simple GTK+2 C application. I've followed this tutorial and this one that deals with sub directories, but I'm running into a problem where my source directory (in the src sub-directory) is not generating a Makefile, though the parent directory's Makefile is getting generated.
First, here is my folder structure:
app/src
- main.c
- main.h
- Makefile.am
app
- configure.ac
- Makefile.am
- aclocal.m4
(... other generated files ...)
Here are the contents of the important files:
app/configure.ac:
AC_PREREQ([2.63])
AC_INIT(app, 0.1)
AM_INIT_AUTOMAKE(app, 0.1)
AC_CONFIG_SRCDIR([src/main.h])
AC_CONFIG_HEADERS([config.h])
# Checks for programs.
AC_PROG_CC
# Checks for libraries.
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
AC_CONFIG_FILES([Makefile], [src/Makefile])
AC_OUTPUT
app/Makefile.am:
SUBDIRS = src
app/src/Makefile.am:
bin_PROGRAMS = app
app_SOURCES = main.c
app_LDADD = `pkg-config --cflags --libs gtk+-2.0`
Here is what happens when I run the following commands:
$ autoconf
$ automake -a
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
configure: creating ./config.status
config.status: creating Makefile
./config.status: line 1153: src/Makefile: No such file or directory
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
When I check, the main app folder gets a Makefile and Makefile.in, but the src folder still only has the Makefile.am. Any ideas?
UPDATE: I made the changes mentioned by adl, namely, I removed the square brackets and comma from the AC_CONFIG_FILES command and removed the app name/version from the AM_INIT_AUTOMAKE command. I also changed the app_LDADD command in src/Makefile.am to app_LDFLAGS. This has fixed my initial problem of not getting through a configure, but now it isn't looking for the gtk libraries. When I do a make I get something like the following:
$ make
make all-recursive
make[1]: Entering directory `/home/adam/Development/app-0.1'
Making all in src
make[2]: Entering directory `/home/adam/Development/app-0.1/src'
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" \
-c -o main.o `test -f 'main.c' || echo './'`main.c; \
then mv -f ".deps/main.Tpo" ".deps/main.Po"; \
else rm -f ".deps/main.Tpo"; exit 1; \
fi
main.c:3:21: error: gtk/gtk.h: No such file or directory
In file included from main.c:4:
main.h:4: error: expected specifier-qualifier-list before ‘GtkWidget’
Here is what I get with pkg-config:
$ pkg-config --libs --cflags gtk+-2.0
-D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
I'm pretty sure I'm doing something wrong in my src/Makefile.am, but I don't know what. If it helps, my configure script does not appear to be looking for any gtk libs.
UPDATE2:
So the basic solution for the problem in update1 seems to be that I needed to add the following check to my configure.ac file:
PKG_CHECK_MODULES(GTK, [gtk+-2.0 >= 2.12])
PACKAGE_CFLAGS="-g -Wall $GTK_CFLAGS"
PACKAGE_LIBS="-g $GTK_LIBS"
PACKAGE_LDFLAGS="-export-dynamic $GTK_LDFLAGS"
AC_SUBST([PACKAGE_CFLAGS])
AC_SUBST([PACKAGE_LIBS])
AC_SUBST([PACKAGE_LDFLAGS])
This gets added to the checks for programs section under AC_PROG_CC. What this does is tell configure to check for the gtk+-2.0 library. The upper case GTK seems to be an arbitrary variable name, and the CFLAGS, LIBS, and LDFLAGS (and probably more) gets added to it dynamically so that you can generate the PACKAGE_* variables. The AC_SUBST seems to make it so you can access the PACKAGE* variables in your Makefile.am's. FYI, the -export-dynamic flag is added so that you can use glade/gtkbuilder files (I'm sure there are other reasons, but I'm still at a very basic level of understanding).
In src/Makefile.am, you should have:
bin_PROGRAMS = app
app_SOURCES = main.c main.h
app_LDADD = #PACKAGE_LIBS#
app_LDFLAGS = #PACKAGE_LDFLAGS#
INCLUDES = #PACKAGE_CFLAGS#
This seems to be all you need for a basic gtk+-2.0 C app. It has actually inspired me to write a simple tutorial for setting up a C gtk app that uses autotools. There is a definite lack of recent beginner documentation/information in this field.
Two issues in your configure.ac file. First, the syntax of your AM_INIT_AUTOMAKE invocation is 10 year old, I suspect you copied it from a very old tutorial (hint: the Automake manual has a tutorialish introduction). You've already passed the package and version to AC_INIT, there is no need to repeat that in AM_INIT_AUTOMAKE. Second, the list of files passed to AC_CONFIG_OUTPUT should be a space-separated list given as first argument.
In other words, your configure.ac should look like
AC_PREREQ([2.63])
AC_INIT([app], [0.1], [your#email])
AM_INIT_AUTOMAKE([-Wall])
AC_CONFIG_SRCDIR([src/main.h])
AC_CONFIG_HEADERS([config.h])
AC_PROG_CC
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUT
Note there is no coma on the AC_CONFIG_FILES line.
The -Wall option will cause automake to output more warnings (this really is an automake option, not a gcc option), it's probably safer if you discover these tools.
This should fix your configure problem. Then I suspect you'll probably have to split your app_LDADD line into app_CPPFLAGS and app_LDFLAGS.
A few more issues that haven't been mentioned yet:
Use autoreconf to (re)generate configure and Makefile.in. It calls the requisite tools in the correct order.
Prefer using the make macros (“$(FOO)”) to the Autoconf substitutions (“#FOO#”) in your makefile. The advantage of the former is that they can be overridden at make time should that be necessary.
I'd encourage you to create a separate build directory and run configure there rather than building in the source directories. This is a setup that you probably don't want to break; and if you aren't testing it, you can inadvertently break it.
Rather than adding GTK_CFLAGS and GTK_LDFLAGS to your PACKAGE_CFLAGS, you can simply do:
app_LDADD = #PACKAGE_LIBS# #GTK_LIBS#
or, if every app depends on gtk, just do
LDADD = #GTK_LIBS#
Specifying -g and -Wall the way you are is not really a good thing. You can do it more easily by defining AM_CFLAGS, and while that's fine for -Wall, you really don't want -g in there. The default configure will add -g to CFLAGS, and if the user overrides CFLAGS when configure is run, you should trust them to know what they're doing and give them the freedom to skip -g. If you are adding -g for your own convenience (so you don't need to specify -g when you specify CFLAGS at configure time), it would be more appropriate to use a CONFIG_SITE rather than hardcoding the -g in you project's build files.
Another option for this could be the following:
AM_PATH_GTK_2_0([Min version], [Succes], [Failure])
AM_PATH_GLIB_2_0([Min version], [Succes], [Failure])
It's always a good idea to take a look at what your aclocal directory (/usr/aclocal) holds as macro possibilities. Also don't forget to run aclocal so that the required M4 macros gets copied to aclocal.m4.
Related
I have a project that basically compiles from the command line in the following form:
g++ -o stack_raster stack_raster.cpp -lgdal -lboost_filesystem -lboost_system
I made a Makefile, and this is the content:
CXX =g++
LDDFLAGS = -lgdal -lboost_system -lboost_filesystem
all: clean stack_raster
clean:
rm -f stack_raster
However I got a collect2: error: ld returned 1 exit status.
A second variation of my Makefile I tried was:
CXX = g++
CPPFLAGS = -lgdal -lboost_system -lboost_filesystem
all: clean stack_raster
clean:
rem -f stack_raster
but I still receive the following message (even though the compile flags appear as they should for my program to compile successfully).
collect2: error: ld returned 1 exit status
<builtin>: recipe for target `stack_raster` failed
make: *** [stack_raster] Error 1
Does anyone could help me with a reference or hint about my problem, and how could I tackle it?
Does anyone could help me with a reference or hint about my problem, and how could I tackle it?
To begin with, you should have a look at the actual link command that make executed. It should have been echoed to make's output just before the error message from collect2. Understanding what's wrong with the command is the first step in determining how to fix your makefile.
In the first case, the command is probably something like
g++ stack_raster.cpp -o stack_raster
In the second, it is probably something like
g++ -lgdal -lboost_system -lboost_filesystem stack_raster.cpp -o stack_raster
The latter is probably also very similar to what you would get with the first makefile if you corrected the spelling of LDDFLAGS to LDFLAGS.
You will note that the library flags come in a different place in that command than they do in your manual command, and I assume you know that the order of objects and library flags on the linker command line is significant to Unix-style linkers such as GNU's (which is the one that the g++ driver will use).
You can certainly fix this by writing an explicit rule, as you describe in your own answer, but your makes' built-in rules may be up to the task, too. If you are using GNU make then they certainly are. For this purpose it is useful to know what the built-in rules actually are, and essential to know what the variables on which these rules depend mean.
Specifically,
LDFLAGS provides options to pass when invoking the linker, and conventionally, they appear on the command line before the objects being linked. As a result, this variable typically is not appropriate for specifying libraries (but it is fine for other link-specific options, such as -L to add directories to the library search path).
CPPFLAGS provides options for modulating the behavior of the C preprocessor (including when compiling C++). These do not typically appear at all in link(-only) commands executed by make, but they will appear (early) in commands for compiling object files from C or C++ sources, and in rules for building executables directly from C or C++ sources.
Neither of those is what you want, but if you are using GNU make, then its documentation for the former explicitly tells you what (with that make implementation) you should do instead:
Extra flags to give to compilers when they are supposed to invoke the
linker, ‘ld’, such as -L. Libraries (-lfoo) should be added to the
LDLIBS variable instead.
(emphasis added)
In GNU make, and perhaps some others, the LDLIBS variable serves exactly the purpose you need: to specify the libraries to link. These will appear at the end of the link command line from built-in rules, as you can confirm from GNU make's catalog of implicit rules, or from the list obtainable by running make -p in a directory containing no makefile.
So, with GNU make you can get the build you seem to want from the built-in rules, with this:
CXX = g++
LDLIBS = -lgdal -lboost_system -lboost_filesystem
all: clean stack_raster
clean:
rm -f stack_raster
In closing, I note that cleaning before building by default, as your examples do and mine imitates, largely defeats the purpose of using make instead of a simple script. Part of the point of make is to do the minimum work necessary, and if your target executable is present and not out of date with respect to its sources then there is no reason to force it to be rebuilt.
Check out the answer:
Set up my makefile to compile C with just "make"
YOu have to specify in the Makefile the file you want to create in this case stack_raster.exe and the objective file in this case stack_raster.cpp and specify the command line arguments you normally pass for compiling. So the Makefile would be something like:
CXX=g++
stack_raster.exe: stack_raster.cpp
g++ -o stack_raster.exe stack_raster.cpp -lgdal -lboost_filesystem -lboost_system
all: clean stack_raster.exe
clean:
rm -f stack_raster.exe
OS: FreeBSD 11.0-RELEASE
I have the following directory structure:
/xxx/obj/
/xxx/src/deep.cpp
/xxx/flat.cpp
/xxx/makefile
The content of makefile is as follows:
flat.out: flat.o
deep.out: src/deep.o
I have no problem building flat:
/xxx $ make flat.out
c++ -O2 -pipe -c /xxx/flat.cpp -o flat.o
cc -O2 -pipe flat.o -o flat.out
/xxx $ ls obj
flat.o flat.out
But when I try to build deep it fails:
/xxx $ make deep.out
c++ -O2 -pipe -c /xxx/src/deep.cpp -o src/deep.o
error: unable to open output file 'src/deep.o': 'No such file or directory'
1 error generated.
*** Error code 1
Stop.
make: stopped in /xxx
If I then create /xxx/obj/src manually it succeeds:
/xxx $ mkdir obj/src
/xxx $ make deep.out
c++ -O2 -pipe -c /xxx/src/deep.cpp -o src/deep.o
cc -O2 -pipe src/deep.o -o deep.out
/xxx $ ls obj
deep.out flat.o flat.out src
/xxx $ ls obj/src
deep.o
According to this source bmake (aka bsdmake?) supports automatic creation of out-of-source OBJDIRs, but I cannot figure out how exactly.
How do I configure bmake to create the relevant directories automatically, in the general case?
Automatic creation of out-of-source OBJDIRs is supported but not in the sense you seem to expect it. Creation of out-of-source OBJDIRs can be implemented with bmake(1) directives but is not supported by the bmake(1) program itself. That said,
If you use bmake(1) directives shipped with FreeBSD to build your project, then the creation of OBJDIRs is supported and implemented by the obj target, so that the command make obj will create the OBJDIRs. See the file bsd.obj.mk for further documentation and implementation details. FreeBSD sources contain a lot of examples of programs using these directives to build.
If you use bmake(1) directives shipped as the (portable) bsdowl package, then the creation of OBJDIRs is supported and implemented by the target obj so that the command make obj or the command make preparatives using a more general target will create the OBJDIRs. The example directory contains several C-based examples showing how to prepare your Makefiles to build your project with the bsdowl package.
If you use custom bmake(1) directives, then you will have to implement a target taking care of this creation yourself. The file bsd.obj.mk is definitely a good source to get started with this.
An important point to note, is that bmake(1) determines its actual working directory before processing any targets, which means that it is almost always the right thing to do to execute the target requesting the creation of OBJDIRs on its own. Because of this, the command bmake obj all from your example would fail with the same error message you reported above. The correct invocation would instead be bmake obj && bmake all, since the second bmake(1) process has now the chance to change to the OBJDIR created by the previous run.
The autotools documentation is very confusing. I am writng Fortran, so the AM_CFLAGS equivalent is AM_FCFLAGS. The two work exactly the same way (presumably).
First off, what actually "is" AM_CFLAGS, conceptually? Clearly, the "CFLAGS" bit is to do with setting compiler flags. But what does the "AM_" part mean?
There seems to be conflicting advice as to how to use it. Some say don't put it in Makefile.am, and some say don't put it in configure.ac. Who is right?
Here is my current Makefile.am:
AM_FCFLAGS = -Wall -O0 -C -fbacktrace
.f90.o:
$(FC) -c $(AM_FCFLAGS) $<
What I want to happen is to compile with "-Wall -O0 -C -fbacktrace" by default if I'm compiling with gfortran. However, a user might want to use a different compiler, eg FC=ifort, in which case they'll probably have to pass in FCFLAGS="whatever" and completely scrap AM_FCFLAGS
Can the user also override the default AM_FCFLAGS from the configure option if they're still using gfortran?
Basically, WTF?
AM_FCFLAGS (and similarly AM_CFLAGS and similar) are designed to not be user-overridable, so you should not put those options there unless you want them to always be present.
Users can pass their own FCFLAGS as part of their ./configure call — what you can do, if you want to default to those rather than what autoconf will default by itself, is to change configure.ac and compare the default flags (which to be honest I don't know for Fortran) to the current FCFLAGS, and if they match, replace FCFLAGS with your defaults.
In Makefile.am I had
AM_CFCFLAGS = -Wall -O0 -C -fbacktrace
Bad idea! It assumes that folks are using gfortran and/or won't want to override those defaults. So I deleted that line.
Instead, I now have the following lines in configure.ac:
AC_PROG_FC([gfortran], [Fortran 90]) # we need a Fortran 90 compiler
AS_IF([test x$FC = xgfortran -a x$ac_cv_env_FCFLAGS_set = x],
AC_SUBST([FCFLAGS], ["-Wall -O0 -C -fbacktrace"])
[Set some flags automatically if using gfortran])
AC_PROG_FC checks for gfortran that meets with Fortran 90 standards, and automatically sets FC and FCFLAGS.
The last 3 lines set sensible defaults if the user is using gfortran, but hasn't set FCFLAGS.
I discovered about ac_cv_env_FCFLAGS_set when I looked at config.log. It is set to "set" if the user sets their own FCFLAGS.
In Makefile.am I now have rules like:
.f90.o:
$(FC) -c $(FCFLAGS) $<
datetime_module.mod : datetime.o
datetime.o : datetime.f90 mod_clock.o mod_datetime.o mod_strftime.o mod_timedelta.o
mod_clock.o: mod_clock.f90 mod_datetime.o mod_timedelta.o
mod_datetime.o: mod_datetime.f90 mod_constants.o mod_strftime.o mod_timedelta.o
mod_timedelta.o: mod_timedelta.f90
It's starting to make sense now.
I'm trying to compile AODV for ARM linux. I use a SabreLite as a board with kernel version 3.0.35_4.1.0. It's worth mention that i'm using openembedded to create my Linux Distribution for my board.
The AODV source code (http://sourceforge.net/projects/aodvuu/) has a README file which give some indications on how to install it on ARM as stated a bit here.
(http://w3.antd.nist.gov/wctg/aodv_kernel/kaodv_arm.html).
I was able to upgrade the makefile in order to be used with post 2.6 kernel version ( as stated above, i have the 3.0.35_4.1.0 kernel version).
So, basically, what i am trying to do is that i have to create a module (let's say file.ko) and then load it into the ARM (with insmod file.ko command).
To do that, i am using a cross compiler which some values are stated below:
echo $CC :
arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi
echo $ARCH=arm
echo $CFLAGS: O2 -pipe -g -feliminate-unused-debug-types
echo $LD :
arm-oe-linux-gnueabi-ld --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi
echo $LDFLAGS :
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--as-needed
when i launch "make command", i get the following errors:
LD [M] /home/scof/script_emulation/AODV/aodv-uu/lnx/kaodv.o
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
arm-oe-linux-gnueabi-ld: use the --help option for usage information
It states that there is something wrong with the linker. This linker comes from the cross compilation tools and i normally shouldn't touch it.
Anyway, to get this above errors fixed, i try to withdraw the LDFLAGS like this:
export LDFLAGS='',
and after this, the make command works and i get the module kaodv.ko. But when i insert it into my ARM to check, it does not work. It actually freeze my terminal
So my question is, do i have to specify the LDFLAGS when compiling ? Does withdrawing LDFLAGS can have impact on the generated kernel module.
Actually, i try to understand where might be the problem and the only thing that come to me is that may be i should not change manually the LDFLAGS. But if i don't change de LDFLAGS, i get the unrecognized option error.
My second question related to that is, what are the possibly value of LDFLAGS
in ARM compilation
Thanks !!
echo $LDFLAGS : -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--as-needed
There are two common methods of invoking the linker in a GCC-based toolchain. One is to do it directly, but another is to use GCC as a front end to invoke the linker, rather than invoke it directly. When doing this, options intended for the linker are prefixed with -Wl, so that GCC knows to pass them through rather than interpret them itself.
In your case the error message from LD itself
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
Indicates that your build system is passing LDFLAGS directly to the linker, and not by way of GCC.
Therefore, you should remove the -Wl, prefix and your LDFLAGS would instead be
-O1 --hash-style=gnu --as-needed --as-needed
(the duplication of the last argument is probably pointless but benign)
-O1 is an option that tells the linker to optimize. I believe it something new, and your linker may be slightly out of date. Try removing -Wl,-O1, it should still work.
I am new to automake tools. In "src/Makefile.am", I use "AM_LDFLAGS = -L... -l...".
Then, I run "autoreconf --force --install ; ./configure ; make"
In the last command,
$ g++ -O2 -L... -l... -o target_name [some *.o files]
the compiler complains "undefined reference to ...".
But if I copy it and move "-L... -l..." to the end, and run it independently it is fine (below).
$ g++ -O2 -o target_name [some *.o files] -L... -l...
So the order of options does matter? Anyway, how to smooth it?
Thanks a lot.
For the "-L" options, try using the LDADD or target_name_LDADD variable instead (where target_name is replaced with the actual target name). This places these flags at the end of the linking command.
The order of "-l" and "-L" does make a difference. From http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html:
-l library
Search the library named library when linking. ... It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, ‘foo.o -lz bar.o’ searches library ‘z’ after file foo.o but before bar.o. If bar.o refers to functions in ‘z’, those functions may not be loaded. ... The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined.
So libraries should appear after object files/other libraries that depend upon them.