What I'm going for (what's failing)
I have a list of dependencies for each file:
point_deps =
bounds_deps = point
triangle_deps = point bounds
Image_deps = types bounds triangle
main_deps = Image triangle bounds point types
I'd like to write a rule to include the relevant dependencies. Here's my best attempt:
out/%.o: src/%.cpp src/%.h $$($$*_deps:%=src/%.h)
g++ -o $# -c $<
I expect $* to evaluate to, for instance, "main". Then the suffix-changing substitution should change each entry in the dependency list to begin with "src/" and end with ".h".
When I try to run the code above, I get an error (on the out/%.o line):
makefile:26: *** multiple target patterns. Stop.
What's working (non-optimal)
For now I have to create a separate variable for each file's header dependencies:
point_deps_h = $(point_deps:%=src/%.h)
bounds_deps_h = $(bounds_deps:%=src/%.h)
triangle_deps_h = $(triangle_deps:%=src/%.h)
Image_deps_h = $(Image_deps:%=src/%.h)
main_deps_h = $(main_deps:%=src/%.h)
Then I can use secondary-expansion to include the correct header files:
out/%.o: src/%.cpp src/%.h $$($$*_deps_h)
g++ -o $# -c $<
Related
I'm trying to get conditional assignment in a makefile target, only if it was not set by the requiring target:
REPO_PROD = prod
REPO_DEV = dev
.PHONY: ko-build-container
ko-build-container: KO_DOCKER_REPO ?= $(REPO_PROD)
ko-build-container:
#echo $(KO_DOCKER_REPO)
.PHONY: ko-build-container-dev
ko-build-container-dev: KO_DOCKER_REPO = $(REPO_DEV)
ko-build-container-dev: ko-build-container
Unfortunately make ko-build-container-dev prints prod.
What am I missing here ?
Another alternative is to use a third target, like:
ko-build-container-base:
echo $(KO_DOCKER_REPO)
ko-build-container: KO_DOCKER_REPO = $(REPO_PROD)
ko-build-container: ko-build-container-base
ko-build-container-dev: KO_DOCKER_REPO = $(REPO_DEV)
ko-build-container-dev: ko-build-container-base
Apparently, with GNU make, the outcome of the conditional assignment (assign or not assign) is decided in a phase where only global variables are available, but the selection of the final value comes from a later phase where inherited target-specific variables are also available. So, even more bizarre than what you observed, after skipping a conditional assignment because a global variable was set, the final value is not necessarily that of the global variable, it can be inherited from a parent target! Demo:
$ cat Makefile
.PHONY: sub all
all: VAR = all
all: sub
# no global VAR set => assign instead of using inherited VAR = all
sub: VAR ?= sub
sub:
#echo $(VAR)
$ make
sub
$ cat Makefile
.PHONY: all
VAR = global
# global VAR set => do not assign, use global VAR = global
all: VAR ?= all
all:
#echo $(VAR)
$ make
global
$ cat Makefile
.PHONY: sub all
VAR = global
all: VAR = all
all: sub
# global VAR set => do not assign... but use inherited VAR = all
sub: VAR ?= sub
sub:
#echo $(VAR)
$ make
all
This strange behavior is reported here: https://savannah.gnu.org/bugs/?18305 and there is also a discussion about whether it should/could be fixed.
Separating the outcome from the selection of the value in conditional assignments is clearly a bug, I think. Nobody would imagine such a weird behavior. Anyway, instead of a target-specific conditional assignment you could use the workaround suggested in the discussion:
$ cat Makefile
REPO_PROD = prod
REPO_DEV = dev
.PHONY: ko-build-container
ko-build-container:
#echo $(or $(KO_DOCKER_REPO),$(REPO_PROD))
.PHONY: ko-build-container-dev
ko-build-container-dev: KO_DOCKER_REPO = $(REPO_DEV)
ko-build-container-dev: ko-build-container
$ make ko-build-container-dev
dev
I am currently trying to configure tinydtls as described in the README in order to later include it into an application, or at least, make the examples run.
The first steps, including the resulting warnings:
home/name/contiki/apps/tinydtls$ autoreconf
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
home/name/contiki/apps/tinydtls$ ./configure --with-contiki
home/name/contiki/apps/tinydtls$ make
with both TARGET=native and TARGET=zoul
The compilation always ends with (many) undefined reference errors:
obj_zoul/dtls.o: In function dtls_add_ecdsa_signature_elem':
dtls.c:(.text.dtls_add_ecdsa_signature_elem+0x10): undefined reference to `dtls_ec_key_from_uint32_asn1'
dtls_ec_key_from_uint32_asn1 is located in contiki/apps/tinydtls/crypto.c.
Adding #include crypto.h in dtls.c doesn't fix the problem, but #include crypto.c does (fix this first error). Accordingly I assume the problem must have to do something with the linking.
How should the Makefile, of which I pasted a (hopefully significant) part under this question, be adjusted?
SHELL = /bin/sh
MKDIR = mkdir
ETAGS = /bin/false
prefix = /usr/local
exec_prefix = ${prefix}
abs_builddir = /home/name/contiki/apps/tinydtls
top_builddir = .
libdir = ${exec_prefix}/lib
includedir = ${prefix}/include/tinydtls
package = tinydtls-0.8.2
install := cp
# files and flags
SOURCES:= dtls.c crypto.c ccm.c hmac.c netq.c peer.c dtls_time.c session.c
ifneq ("", "1")
SOURCES += debug.c
endif
SUB_OBJECTS:=aes/rijndael.o ecc/ecc.o sha2/sha2.o
OBJECTS:= $(patsubst %.c, %.o, $(SOURCES)) $(SUB_OBJECTS)
HEADERS:=dtls.h hmac.h debug.h dtls_config.h uthash.h numeric.h crypto.h global.h ccm.h \
netq.h t_list.h alert.h utlist.h prng.h peer.h state.h dtls_time.h session.h \
tinydtls.h
CFLAGS:=-Wall -pedantic -std=c99
CPPFLAGS:= -DDTLSv12 -DWITH_SHA256 -DDTLS_CHECK_CONTENTTYPE
SUBDIRS:=tests doc platform-specific sha2 aes ecc
DISTSUBDIRS:=$(SUBDIRS) examples/contiki
DISTDIR=$(top_builddir)/$(package)
FILES:=Makefile.in configure configure.in dtls_config.h.in tinydtls.h.in \
Makefile.tinydtls $(SOURCES) $(HEADERS)
LIB:=libtinydtls.a
LDFLAGS:=
ARFLAGS:=cru
doc:=doc
Edit: Changed the directory for this post to /home/name/...
Edit2: Added warnings after 'autoreconf'.
GCC allows querying available warning flags specific for C++ language with the syntax:
g++ -Q --help=warning,c++
Adding warning flags to the call includes them in the result:
g++ -Wall -Q --help=warning,c++
However, it seems the call is done from the C point of view and I don't know how to do it from the C++ point of view. If the call includes C++-only warning, like:
g++ -Wnon-virtual-dtor -Q --help=warning,c++
the output contains a message:
cc1: warning: command line option ‘-Wnon-virtual-dtor’ is valid for C++/ObjC++ but not for C
and still shows the warning as disabled:
-Wnon-virtual-dtor [disabled]
Note, that this happens regardless of whether the call is done using g++ or gcc.
The same with C-only -Wbad-function-cast behaves in an expected way:
gcc -Wbad-function-cast -Q --help=warning,c
There is no extra message and reported warning status changes between [disabled] and [enabled]. Again, regardless of whether g++ or gcc is used.
I'm using GCC version 7.3.0. Although the issue seems to apply to many if not all versions. It can be observed through Compiler Explorer.
So, is there a way to do this query with respect to given language?
Yes, your observations are correct.
Probably this is not the intended behavior, and if you care about this feature, then I suggest reporting it upstream.
Note that this works, however:
touch 1.cc
g++ -Wnon-virtual-dtor -Q --help=warning,c++ 1.cc
I.e. if there's an input file with a proper extension, then the correct compiler proper executable is invoked: cc1plus, not cc1. The latter is the default if no input files are present. I did some quick debugging, and here's how that happens:
// gcc.c:
driver::do_spec_on_infiles () const
{
...
for (i = 0; (int) i < n_infiles; i++)
{
...
/* Figure out which compiler from the file's suffix. */
input_file_compiler
= lookup_compiler (infiles[i].name, input_filename_length,
infiles[i].language);
if (input_file_compiler)
{
...
value = do_spec (input_file_compiler->spec);
And input_file_compiler at that point is the C compiler, because
p n_infiles
$9 = 1
(gdb) p infiles[0]
$10 = {name = 0x4cbfb0 "help-dummy", language = 0x4cbfae "c", incompiler = 0x58a920, compiled = false, preprocessed = false}
Here's how the dummy file got created (function process_command in the same file):
if (n_infiles == 0
&& (print_subprocess_help || print_help_list || print_version))
{
/* Create a dummy input file, so that we can pass
the help option on to the various sub-processes. */
add_infile ("help-dummy", "c");
}
I have in the /bin folder a file program.cc.
The following Makefile statements
BINS = $(wildcard bin/*.cc)
EXECS = $(notdir $(BINS))
EXECSR = $(EXECS:.cc=)
mean that EXECSR is program
I try to avoid the intermediary variable EXECS in the above statements
BINS = $(wildcard bin/*.cc)
EXECSR = $($(notdir $(BINS)):.cc=)
but this approach fails - EXECSR is empty. How should I modify the Makefile to avoid the intermediary variable EXECS?
EXECSR = $(notdir $(BINS:.cc=))
When building one kernel image for arm32 platform, in the final linking, the error is:
arm-eabi-ld -EL -p --no-undefined -X --build-id -o .tmp_vmlinux1 -T obj/KERNEL/arch/arm/kernel/vmlinux.lds arch/arm/kernel/head.o init/built-in.o --start-group usr/built-in.o arch/arm/vfp/built-in.o arch/arm/kernel/built-in.o arch/arm/mm/built-in.o arch/arm/common/built-in.o arch/arm/net/built-in.o arch/arm/crypto/built-in.o arch/arm/mach-sc/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o arch/arm/lib/lib.a lib/lib.a arch/arm/lib/built-in.o lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o arch/arm/oprofile/built-in.o net/built-in.o --end-group
drivers/built-in.o:
undefined reference to `__aeabi_ldivmod'
make[2]: *** [vmlinux] Error 1
I know the reason is my using 64bit divison for arm32 which 64bit is not supported, and using do_div() can get rid of the __aeabi_ldivmod error. I know __aeabi_ldivmod is defined in the libgcc.a, so I added the following code in my Kernel Makefile:
--- a/Makefile
+++ b/Makefile
## -677,6 +677,7 ##
LDFLAGS_BUILD_ID = $(patsubst -Wl$(comma)%,%,\
$(call cc-ldoption, -Wl$(comma)--build-id,))
KBUILD_LDFLAGS_MODULE += $(LDFLAGS_BUILD_ID)
LDFLAGS_vmlinux += $(LDFLAGS_BUILD_ID)
+LDFLAGS_vmlinux += -L$(MY_LIBPATH) -lgcc
But it still can't work, so can anybody help on my questions:
1) Why the libgcc.a is not linked default in the kernel building?
2) How to link the libgcc.a to fix the link error?
[Update]
OK, I found the following note for -lgcc in OSDev wiki:
-lgcc
You disable the important libgcc library when you pass -nodefaultlibs (implied by -nostdlib). The compiler needs this library for many operations that it cannot do itself or that is more efficient to put into a shared function. You must pass this library near the end of the link line, after all the other object files and libraries, or the linker won't use it and you get strange linker errors.
So I hard coded -L${MYLIB_PATH} -lgcc into into scripts/link-vmlinux.sh:
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
## -55,7 +55,7 ## vmlinux_link()
if [ "${SRCARCH}" != "um" ]; then
${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} \
-T ${lds} ${KBUILD_VMLINUX_INIT} \
- --start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}
+ --start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1} -L${MYLIB_PATH} -lgcc
else
${CC} ${CFLAGS_vmlinux} -o ${2} \
-Wl,-T,${lds} ${KBUILD_VMLINUX_INIT} \
Then the build went without __aeabi_ldivmod error.
While I want to find the better modifying than just harding coding and to know why kernel doesn't link libgcc default.
Don't edit scripts/link-vmlinux.sh, edit only certain Makefiles. For example if you have this error:
drivers/power/reset/msm-poweroff.c:249: undefined reference to `lge_set_restart_reason'
run cscope -R inside top of linux kernel source code directory, then find global definition for lge_set_restart_reason, it finds file definition in include/soc/qcom/lge/lge_handle_panic.h
But lge_handle_panic.h has only definition of lge_set_restart_reason, you need lge_handle_panic.c, which has this function, looking like this:
void lge_set_restart_reason(unsigned int reason)
{
writel_relaxed(reason, RESTART_REASON);
if(use_hardreset) {
qpnp_pon_set_restart_reason(map_imem_reboot_to_pmic(reason));
qpnp_pon_system_pwr_off(PON_POWER_OFF_HARD_RESET);
}
}
so you need to edit drivers/power/reset/Makefile to include lge_handle_panic.o object file:
obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o lge_handle_panic.o
In custom kernels, a lot of functions is enabled by config, what I mean is:
#ifdef CONFIG_LGE_HANDLE_PANIC
static void __iomem *msm_timer0_base;
void __iomem *wdt_timer_get_timer0_base(void)
{
return msm_timer0_base;
}
static void wdt_timer_set_timer0_base(void __iomem * iomem)
{
msm_timer0_base = iomem;
}
#endif
You need enable CONFIG_LGE_HANDLE_PANIC, or any config if you have again this error, or remove "ifdef" and "endif" (I'm not recommending doing this)