I created a simple test application + library that I am building using autotools. The problem is that the Makefile that is generated doesn't understand the "all" target.
Makefile.am:
ACLOCAL_AMFLAGS = -I m4
SUBDIRS = src
VERSION=0:0:0
EXTRA_DIST = autogen.sh
bin_PROGRAMS = testApp
libtest_la_SOURCES = src/testLibrary.c
libtest_la_LDFLAGS = -version-info ${VERSION}
testApp_SOURCES = src/testApp.c
testApp_LDADD = libtest.la
lib_LTLIBRARIES = libtest.la
configure.ac:
AC_INIT(foobar, 1.0, me#mail.com)
AC_CONFIG_AUX_DIR(config)
AC_CONFIG_SRCDIR(src)
AC_PROG_CC
AM_PROG_CC_C_O
LT_INIT
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([subdir-objects])
AC_OUTPUT(Makefile)
Output of the command "make":
Making all in src
make[1]: *** No rule to make target `all'. Stop.
make: *** [all-recursive] Error 1
Yet make understands the "testApp" target and builds it successfully. From my limited knowledge of autotools, the bin_PROGRAMS variable should supply the "all" target with its data?
You seem to be combining recursive and non-recursive make rules.
If you remove this line:
SUBDIRS = src
this error might go away. It's looking for an all rule in src/Makefile.
Related
I am trying to build a Xilinx XDMA driver for Yocto, using their supplied makefile. When I run my recipe the build fails with the following errors:
DEBUG: Executing shell function do_compile
NOTE: make -j 32 KERNEL_SRC=./tmp/work-shared/intel-corei7-64/kernel-source
KERNEL_PATH=./tmp/work-shared/intel-corei7-64/kernel-source
KERNEL_VERSION=5.10.78-intel-pk-standard CC=x86_64-poky-linux-gcc
-fuse-ld=bfd
-fmacro-prefix-map=./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0=/usr/src/debug/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0
-fdebug-prefix-map=./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0=/usr/src/debug/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0
-fdebug-prefix-map=./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/recipe-sysroot=
-fdebug-prefix-map=./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/recipe-sysroot-native=
-fdebug-prefix-map=./tmp/work-shared/intel-corei7-64/kernel-source=/usr/src/kernel LD=x86_64-poky-linux-ld.bfd
AR=x86_64-poky-linux-ar
O=./tmp/work-shared/intel-corei7-64/kernel-build-artifacts KBUILD_EXTRA_SYMBOLS=
Makefile:17: XVC_FLAGS: .
make -C /lib/modules/5.13.0-40-generic/build
M=./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma modules
make[1]: Entering directory '/usr/src/linux-headers-5.13.0-40-generic'
make[2]: Entering directory './tmp/work-shared/intel-corei7-64/kernel-build-artifacts'
./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma/Makefile:17: XVC_FLAGS: .
CC [M] ./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma/libxdma.o
CC [M] ./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma/xdma_cdev.o
x86_64-poky-linux-gcc: error: missing argument to '-gdwarf-'
CC [M] ./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma/cdev_ctrl.o
make[3]: *** [/usr/src/linux-headers-5.13.0-40-generic/scripts/Makefile.build:281: ./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma/libxdma.o] Error 1
make[3]: *** Waiting for unfinished jobs....
x86_64-poky-linux-gcc: error: missing argument to '-gdwarf-'
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.
I have no idea why this happens as it is not something I have specifically enabled. I have searched through the module.bbclass file but I couldn't see anything obvious. I believe that something needs to be configured such that the -gdwarf- actual ends up being set to a valid value (e.g. -gdwarf-2 or -gdwarf-4 etc.)
A grep through the poky repo for dwarf did not reveal anything neither did a search of /usr/src/linux-headers-5.13.0-40-generic/scripts/.
My bitbake recipe is as follows:
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=441c1ecbc199a036abf37f3aa47c5f34"
SRC_URI += https://github.com/Xilinx/dma_ip_drivers.git;protocol=ssh;nobranch=1;branch=master"
# Modify these as desired
PV = "1.0+git${SRCPV}"
SRCREV = "8d7594690058dfa828accc02ac81348e416ffe38"
S = "${WORKDIR}/git/xdma/linux-driver/xdma"
RPROVIDES_${PN} += "xdma"
inherit module
EXTRA_OEMAKE_task-install:append = " -C ${STAGING_KERNEL_DIR} M=${S}"
EXTRA_OEMAKE += "KDIR=${STAGING_KERNEL_DIR}"
The makefile is the standard one from GitHub. The driver builds correctly for Ubuntu using make and I can also build the module if I change my recipe such that it does not include inherit module; this change will build the module (xdma.ko) but does to install it in the roofs. I am also not sure if inherit module includes additional functionality which may be rewired.
How to I either:
prevent / disable the -gdwarf flag being generated
configure the recipe that the -gdwarf- resolves to something valid
View the actual command being invoked that is causing the issue.
Attempts to build the xdma.ko module without the inherit module result in an invalid binary being built, i.e. when I try an load the module on the target I get:
insmod xdma.ko
insmod: ERROR: could not insert module xdma.ko: Invalid module format
Which indicates that the module is compiled from the wrong target.
inherit module is required when building kernel modules for Yocto. If it is omitted the build modules is not compatible with the target.
Workaround for the -gdwarf- error was to manually write a new makefile which is compatible with Yocto:
TARGET_MODULE:=xdma
topdir := $(shell cd $(src)/.. && pwd)
EXTRA_CFLAGS := -I$(topdir)/include
SRC := $(shell pwd)
$(TARGET_MODULE)-objs := libxdma.o xdma_cdev.o cdev_ctrl.o cdev_events.o cdev_sgdma.o cdev_xvc.o cdev_bypass.o xdma_mod.o xdma_thread.o
obj-m := $(TARGET_MODULE).o
all :
$(MAKE) -C $(KERNEL_SRC) M=$(SRC)
modules_install:
$(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
clean:
rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c
rm -f Module.markers Module.symvers modules.order
rm -rf .tmp_versions Modules.symvers
This makefile correctly builds the Xilinx XDMA driver for Yocto. I can confirm that the driver works with Kintex-KC705 FPGA development card.
G'day all. Just to preface this, I'm not an experienced programmer, so I might not use the correct jargon.
I'm in the process of installing GnuPG 2.2.19 on a Windows 10 machine (build no. 18363.628). I have installed MinGW (version 2013072300 according to mingw-get), as well as npth 1.6 and libgpg-error 1.37. I'm now attempting to install libgcrypt 1.8.5. Running ./autogen.sh --build-w32 works, but running make fails with the following output (I am using msys.bat as my shell):
$ make
make all-recursive
make[1]: Entering directory '/c/Users/USER/Downloads/libgcrypt-1.8.5.tar/libgcrypt-1.8.5/libgcrypt-1.8.5'
Making all in compat
make[2]: Entering directory '/c/Users/USER/Downloads/libgcrypt-1.8.5.tar/libgcrypt-1.8.5/libgcrypt-1.8.5/compat'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/c/Users/USER/Downloads/libgcrypt-1.8.5.tar/libgcrypt-1.8.5/libgcrypt-1.8.5/compat'
Making all in mpi
make[2]: Entering directory '/c/Users/USER/Downloads/libgcrypt-1.8.5.tar/libgcrypt-1.8.5/libgcrypt-1.8.5/mpi'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/c/Users/USER/Downloads/libgcrypt-1.8.5.tar/libgcrypt-1.8.5/libgcrypt-1.8.5/mpi'
Making all in cipher
make[2]: Entering directory '/c/Users/USER/Downloads/libgcrypt-1.8.5.tar/libgcrypt-1.8.5/libgcrypt-1.8.5/cipher'
cc -o gost-s-box ./gost-s-box.c
make[2]: cc: Command not found
make[2]: *** [gost-s-box] Error 127
make[2]: Leaving directory '/c/Users/USER/Downloads/libgcrypt-1.8.5.tar/libgcrypt-1.8.5/libgcrypt-1.8.5/cipher'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/c/Users/USER/Downloads/libgcrypt-1.8.5.tar/libgcrypt-1.8.5/libgcrypt-1.8.5'
make: *** [all] Error 2
Unfortunately I accidentally closed the shell window after the first time I ran make, so this is from when I ran it a second time, hence the "Nothing to be done" stuff.
I have checked the Makefile for libgcrypt; it contains the following:
CC = mingw32-gcc
CCAS = mingw32-gcc
CCASDEPMODE = depmode=gcc3
CCASFLAGS = -g -O2
CCDEPMODE = depmode=gcc3
CC_FOR_BUILD = cc
I've checked the MinGW root folder, and gcc.exe and mingw32-gcc.exe are both present in the bin folder. I've also tried changing the first of those lines above to CC=gcc; no change.
Anyone have any suggestions as to what the problem is? Thanks in advance.
Ok, so I managed to solve it myself; after some research, I found that creating a symlink "CC.exe" to "mingw32-gcc.exe" in MinGW's bin did the trick.
I am trying to learn kernel programming but while trying to compile a simple hello world program i am getting the following error.
make −C /lib/modules/3.2.0-67-generic/build M=/home/arun/KPrograms modules
make[1]: Entering directory /home/arun/KPrograms'
make[1]: *** No rule to make target−C'. Stop.
make[1]: Leaving directory `/home/arun/KPrograms'
make: * [all] Error 2
my Makefile is
obj−m += hello−1.o
all:
make −C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make −C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
You should replace all the −C in Makefile into -C. The dash character is incorrect.
Hi all,
You must type your code on your own. In some cases copy paste does not work. You must enter it like this:
obj-m............<enter>
all:....<enter>
<tab>make -C.............<enter>
clean:..............<enter>
<tab>make -C...........<esc> <:wq>
That will probably solve your problem.
good luck
I have a autotool project where part of the source code is downloaded dynamically from the net (because of IP rights preventing direct redistribution) and then built.
I have a Makefile.am that works but I'm not happy about some of it's aspects.
Here it is:
INCLUDES = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir)
AM_CFLAGS = -fPIC -Wall ${SYMBOL_VISIBILITY}
LIBVERSION=0:0:0
REFSRC_PATH=refsrc
REFSRC_SRC=refsrc/dtx.c refsrc/globdefs.c refsrc/host.c refsrc/mathhalf.c refsrc/sp_enc.c refsrc/sp_rom.c refsrc/vad.c refsrc/err_conc.c refsrc/homing.c refsrc/mathdp31.c refsrc/sp_dec.c refsrc/sp_frm.c refsrc/sp_sfrm.c
${REFSRC_PATH}/.downloaded:
./fetch_sources.py "${REFSRC_PATH}"
for f in `ls -1 "${REFSRC_PATH}"/*.{c,h}`; do \
sed -i -e"s/round/round_l2s/" "$$f"; \
done
touch $#
${REFSRC_PATH}/dtx.c: ${REFSRC_PATH}/.downloaded
lib_LTLIBRARIES = libgsmhr.la
libgsmhr_la_SOURCES = libgsmhr.c $(REFSRC_SRC)
clean-local:
-rm -rf ${REFSRC_PATH}
So essentially, libgsmhr.c is my main wrapper, then I download the source code in a refsrc/ subdirectory and patch it a little.
First problem is that in REFSRC_SRC I would have loved to use a $(addprefix ...) instead of repeating refsrc/ in front of each .c file. But that doesn't seem to work and autoreconf complains a little.
Failure details (when removing the refsrc/ prefix from REFSRC_SRC= and using $(addprefix ${REFSRC_PATH}/, ${REFSRC_SRC}) on the dependency list):
bash$ autoreconf -i
libgsmhr/Makefile.am:19: addprefix ${REFSRC_PATH}/, ${REFSRC_SRC}: non-POSIX variable name
libgsmhr/Makefile.am:19: (probably a GNU make extension)
(configure works fine)
bash$ make
...
make[2]: Entering directory `/tmp/ram/gapk.build/libgsmhr'
CC libgsmhr.lo
CCLD libgsmhr.la
make[2]: Leaving directory `/tmp/ram/gapk.build/libgsmhr'
...
(So as you see it didn't include any of the downloaded .c files, didn't even download them at all. The compile works because libgsmhr.c is a stub that doesn't use the symbols in those file yet)
Second problem is this rule:
${REFSRC_PATH}/dtx.c: ${REFSRC_PATH}/.downloaded
I have to explicitely list the first file (dtx.c) instead of using a wildcard like:
${REFSRC_PATH}/%.c: ${REFSRC_PATH}/.downloaded
If I try to use the wildcard, then autoreconf complains and also it just doesn't work ... (pattern doesn't match somehow).
Failure detail:
bash$ autoreconf -i
libgsmhr/Makefile.am:16: `%'-style pattern rules are a GNU make extension
(configure works fine)
bash$ make
...
make[2]: *** No rule to make target `refsrc/dtx.c', needed by `dtx.lo'. Stop.
...
Sylvain
You seem to be writing a makefile in GNUMake style, but actually running some other version of Make. If it's not obvious what autoreconf is calling, you could insert a rule in the makefile:
dummy:
#echo using $(MAKE)
$(MAKE) -v
If this theory proves correct, you can either persuade autoconf to use GNUMake, or write for the version it's using.
I have a makefile with a target clean:
clean:
$(MAKE) -f <other makefile location> clean
When I call make clean in this makefile, it tells me that in the other makefile there is no rule 'clean-linux'. Specifically here is the output.
make -f /root/ovaldi-5.5.25-src/project/linux/Makefile clean
make[1]: Entering directory '/root/ovaldi-5.5.25-src'
make[2]: Entering directory '/root/ovaldi-5.5.25-src'
make[2]: *** No rule to make target 'clean-linux'. Stop.
make[2]: Leaving directory '/root/ovaldi-5.5.25-src'
make[1]: Leaving directory '/root/ovaldi-5.5.25-src'
Why is it giving it the clean-linux target and not just clean like I specified?
When you make (or $(MAKE)), by default you use whatever makefile is there. So here's what I think is happening.
You cd to some location.
You 'make -f Makefile_A clean'.
make runs with Makefile_A, and does '$(MAKE) -f Makefile_B clean'.
make[1] runs with Makefile_B, and does '$(MAKE) clean-linux'.
make[2] runs with whatever makefile is here which might be anything (I suspect it's Makefile_A) but whatever it is it has no rule for clean-linux.
The solution: rewrite your second makefile (the one that has clean-linux) so that clean-linux becomes a prerequisite of clean (if/when you're on a linux system). That way it won't run make[2].
ifeq ($(PLATFORM), LINUX)
clean: clean-linux
endif
ifeq ($(PLATFORM), SUNOS)
clean: clean-sunos
endif
clean:;
Just a guess but maybe the 'clean' target in the second makefile calls 'clean-linux'?
Can you post the clean target of the second makefile?
Edit:
In light of your posted clean target it seems you're just calling the clean-linux target incorrectly.
Beta has posted the correct way of dealing with your problem in their answer so I'm going to +1 that.