I have the following sub-section of makefile that's used to generate the .d files
-include $(wildcard $(patsubst %,$(OBJ_PATH)/%.d,$(basename $(SRCS))))
%.o: %.cpp
#$(CC) -I$(INCLUDE_PATH) $(CFLAGS) $< -MM -MT $(#:.d=.o) > $(OBJ_PATH)/$(notdir $*.d)
${CC} -I$(INCLUDE_PATH) $(CFLAGS) -c $< -o $(OBJ_PATH)/$(notdir $#)
Sometimes when I build the project, I get the following error /bin/sh: /path/to/my/build/dir/file.d: File exists, although .d files does not exist.
Then I keep getting this error, the only way to get rid of it is to remove the whole enclosing directory and use git restore and the system will build successfully.
System info:
git version 2.27.0
GNU Make 4.2.1
Red Hat Enterprise Linux 8.5 (Ootpa)
Free inodes: 426798634
You should remove the # from your line that creates the .d file, so you can see what the command line actually is. It's always a bad idea to add # before your makefile is working 100% correctly. Then you could cut and paste a full failure example into your question, including the command that generated the error message.
Your build lines are not right. During the compilation, you need to use $# not $(OBJ_PATH)/$(notdir $#). It's always wrong to build a file that is not exactly $#.
During the creation of the dependency file $(#:.d=.o) is useless because $# is already set to xxx.o so changing the .d suffix to .o doesn't do anything. You should just use -MT $# here.
You can replace $(OBJ_PATH)/$(notdir $*.d) with the simpler %*.d.
This error is being shown by the shell and there's really no way we can understand what the problem is with the info given. Why would the shell give a "File exists" error when you use ">" to overwrite it?
I have a suspicion that it's not actually this command that is generating that error.
I am trying to learn makefile, but I fail badly.
One example (which is very primitive) but I should understand it to go ahead is this one
f90_simple: f1.o
gfortran f1.o
mv a.out f90_simple
f90_simple.o: f1.f90
gfortran -c f1.f90
it does not work, and I get this error
I get this error
make: *** No rule to make target `f1.o', needed by `f90_simple'. Stop.
could you please advise me?
thanks
Your first rule says that before f90_simple can be built, the target f1.o must be built.
But there's no rule in your makefile that tells make how to build the target f1.o, and make can't find any built-in rule that can build it (based on the source files make has available), so it prints that error.
You do have a rule that tells make how to build a target f90_simple.o... but that's not the target make is looking for. Most likely you want your makefile to either be:
f90_simple: f1.o
gfortran $^
mv a.out $#
f1.o: f1.f90
gfortran -o $# -c $<
or else:
f90_simple: f90_simple.o
gfortran $^
mv a.out $#
f90_simple.o: f1.f90
gfortran -o $# -c $<
but you can't mix and match them, or make doesn't know what to do.
I think you would really benefit from reading at least the introductory chapters in The GNU Make Manual.
I am running the build on linux in fortify mode. Following commands get run inside the build
/usr/local/packages/fortify_360/bin/sourceanalyzer -Xmx1512M -b FORTIFY -Dcom.fortify.sca.ProjectRoot=/ade/ka/dbss/utl/fortify -jdk 1.5 -c /ade/ka_View_12.2/xa/bin/orscript -o /ade/ka/xa/dbsa/bin/avorclcoll -m64 -z noexecstack -Wl,--disable-new-dtags -L/ade/ka/xa/dbsa/lib/ -L/ade/ka/xa/lib/ -L/ade/ka/xa/lib/stubs/ /ade/ka/oracle/dbsa/lib/zaorclmain.o -lclntsh -lclntshcore -lclient12 -lavclient12 -lnnz12 -lmql1 -lipc1 -ldl -lm -lpthread -lnsl -lrt -lc -Wl,-R
when I run this I get error Unrecognized or invalid command line argument '-o'
but if I replace the script /ade/ka_View_12.2/xa/bin/orscript with gcc, it works fine.
My script /ade/ka_View_12.2/xa/bin/orscript has following code, in this code I am just having one variable CC = gcc and "$#" for parameter
#!/bin/sh
#
# $Header: buildtools/port/orald /linuxamd64/3 2012/10/02 19:28:56 ekarichk
#
# orscript
#
CC=gcc
#
# Just use CC for now
#
exec ${CC} "$#"
exit 1
Please help, I have been struggling with this error for long time :(
Examine the help for C/C++ builds by running:
sourceanalyzer -h
You will see that there are several ways of running scans on C/C++ code. One is to directly invoke the compiler, which corresponds to the successful case in your example. If you want to use a build script such as make (or your "orscript") then you should use the touchless argument, such as:
sourceanalyzer -Xmx1512M -b FORTIFY -Dcom.fortify.sca.ProjectRoot=/ade/ka/dbss/utl/fortify touchless /ade/ka_View_12.2/xa/bin/orscript {args}
Note: you also do not need to specify the -jdk argument, since you are not analyzing Java code.
I am facing issues with a make command. I am compiling Scilab on RHEL for ppc64. The ./configure went well, now when I did make all, I have an issue when compiling the module umfpack. I can reproduce this error by entering the modules/umfpack folder, and by typing there make all. This is the output:
enter[root#rhel70-misurio umfpack]# /bin/sh ../../libtool --tag=CC --mode=link gcc -D_LARGEFILE64_SOURCE -DNDEBUG -fno-stack-protector -g -O2 -version-number 5:5:1 -Wl,--no-as-needed -o libsciumfpack.la -rpath /usr/local/lib/scilab sci_gateway/c/libsciumfpack_la-gw_umfpack.lo sci_gateway/c/libsciumfpack_la-sci_res_with_prec.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chdel.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chfact.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chget.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chinfo.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chsolve.lo sci_gateway/c/libsciumfpack_la-sci_umf_ludel.lo sci_gateway/c/libsciumfpack_la-sci_umf_lufact.lo sci_gateway/c/libsciumfpack_la-sci_umf_luget.lo sci_gateway/c/libsciumfpack_la-sci_umf_luinfo.lo sci_gateway/c/libsciumfpack_la-sci_umf_lusolve.lo sci_gateway/c/libsciumfpack_la-sci_umfpack.lo libsciumfpack-algo.la -L-lumfpack -lsuitesparseconfig -lumfpack -lpthread -ldl -lcurses -lm
../../libtool: line 6000: cd: -l: invalid option
cd: usage: cd [-L|[-P [-e]]] [dir]
libtool: link: cannot determine absolute directory name of `-lumfpack'
So it is apparent that somewhere the code is doing "cd -"something. But where...? this is folder where I am.
[root#rhel70-hostname umfpack]# ls
etc libsciumfpack-algo.la make_all_log sci_gateway umfpack.iss
examples license.txt Makefile src UMFPACK_license.txt
help locales Makefile.am TAUCS_license.txt
includes macros Makefile.in tests
Which are the candidates, in your opinion, where I have to investigate where the mistake is? What would you do in my place to debug?
Thanks!
Many thanks for your suggestions! I went into the libtool file and indeed I found that at line 6'000 there was this line of code:
absdir=`cd "$dir" && pwd`
test -z "$absdir" && \
func_fatal_error "cannot determine absolute directory name of \`$dir'"
And I realised that it was doing "cd -lumfpack" in the script. That was an input I had given to the ./configure script, in which I had to explicitly provide the libumfpack and libsuitesparseparseconfig as an option, since it was using other libraries by default. In that option, I had given:
--with-umfpack-library="-lumfpack -lsuitesparseconfig"
so then make was doing "cd -lumfpack". So I thought about providing the absolute path of both libraries! So I gave as input:
--with-umfpack-library="/usr/local/lib/libumfpack.a /usr/local/lib/libsuitesparseconfig.a"
And it successfully ran the configure script and the make.
Another "solution" would have been to remove the umfpack libraries altogether with the option to the configure script:
--without-umfpack
Hope it helps future programmers compiling Scilab!
Honestly, I think another way could have been feasible, that is specifiying the libumfpack and libsuitesparseconfig libraries in the configure script directly, but I didn't have time then to investigate this. If I will do, I will update this post.
I am having problems getting any kernel modules to build on my machine. Whenever I build a module, modpost always says there are zero modules:
MODPOST 0 modules
To troubleshoot the problem, I wrote a test module (hello.c):
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
#include <linux/init.h> /* Needed for the macros */
static int __init hello_start(void)
{
printk(KERN_INFO "Loading hello module...\n");
printk(KERN_INFO "Hello world\n");
return 0;
}
static void __exit hello_end(void)
{
printk(KERN_INFO "Goodbye Mr.\n");
}
module_init(hello_start);
module_exit(hello_end);
Here is the Makefile for the module:
obj-m = hello.o
KVERSION = $(shell uname -r)
all:
make -C /lib/modules/$(KVERSION)/build M=$(shell pwd) modules
clean:
make -C /lib/modules/$(KVERSION)/build M=$(shell pwd) clean
When I build it on my machine, I get the following output:
make -C /lib/modules/2.6.32-27-generic/build M=/home/waffleman/tmp/mod-test modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-27-generic'
CC [M] /home/waffleman/tmp/mod-test/hello.o
Building modules, stage 2.
MODPOST 0 modules
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-27-generic'
When I make the module on another machine, it is successful:
make -C /lib/modules/2.6.24-27-generic/build M=/home/somedude/tmp/mod-test modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.24-27-generic'
CC [M] /home/somedude/tmp/mod-test/hello.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/somedude/tmp/mod-test/hello.mod.o
LD [M] /home/somedude/tmp/mod-test/hello.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.24-27-generic'
I looked for any relevant documentation about modpost, but found little. Anyone know how modpost decides what to build? Is there an environment that I am possibly missing?
BTW here is what I am running:
uname -a
Linux waffleman-desktop 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux
Edit
Here is make ran with V=1:
make -C /lib/modules/2.6.32-27-generic/build M=/home/waffleman/tmp/mod-test modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-27-generic'
test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/linux/autoconf.h or include/config/auto.conf are missing."; \
echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo; \
/bin/false)
mkdir -p /home/waffleman/tmp/mod-test/.tmp_versions ; rm -f /home/waffleman/tmp/mod-test/.tmp_versions/*
make -f scripts/Makefile.build obj=/home/waffleman/tmp/mod-test
gcc -Wp,-MD,/home/waffleman/tmp/mod-test/.hello.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.4.3/include -Iinclude -I/usr/src/linux-headers-2.6.32-27-generic/arch/x86/include -include include/linux/autoconf.h -Iubuntu/include -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i586 -mtune=generic -maccumulate-outgoing-args -Wa,-mtune=generic32 -ffreestanding -fstack-protector -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-larger-than=1024 -fno-omit-frame-pointer -fno-optimize-sibling-calls -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-dwarf2-cfi-asm -fconserve-stack -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hello)" -D"KBUILD_MODNAME=KBUILD_STR(hello)" -c -o /home/waffleman/tmp/mod-test/.tmp_hello.o /home/waffleman/tmp/mod-test/hello.c
set -e ; perl /usr/src/linux-headers-2.6.32-27-generic/scripts/recordmcount.pl "i386" "32" "objdump" "objcopy" "gcc" "ld" "nm" "" "" "1" "/home/waffleman/tmp/mod-test/hello.o";
(cat /dev/null; echo kernel//home/waffleman/tmp/mod-test/hello.ko;) > /home/waffleman/tmp/mod-test/modules.order
make -f /usr/src/linux-headers-2.6.32-27-generic/scripts/Makefile.modpost
scripts/mod/modpost -m -a -i /usr/src/linux-headers-2.6.32-27-generic/Module.symvers -I /home/waffleman/tmp/mod-test/Module.symvers -o /home/waffleman/tmp/mod-test/Module.symvers -S -w -s
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-27-generic'
waffleman#waffleman-desktop:~/tmp/mod-test$ cat /home/waffleman/tmp/mod-test/modules.order
kernel//home/waffleman/tmp/mod-test/hello.ko
I spent all day glued to my computer fighting this precise problem..which ended up mysteriously disappearing like for OP.
I can at least offer this meager detail from my experience: I was getting the same output as OP (for make V=1) and putting print statements in ${kernel_directory}/scripts/makefile.build showed that obj-m was strangely NOT being set after including my makefile, even though it was clearly typed as above.
I did a bunch of fooling around with the line "obj-m += hello.o" and the ones around it. Eventually it magically worked..although it looked exactly the same as before in the end. Maybe I had copied those lines from a tutorial online and it contained some sort of invalid/incorrect character?
For anyone experiencing this, verify that obj-m is in fact getting set to hello.o
If it mysteriously isn't, delete the line, hell the whole Makefile, and retype it.
I know that's not much help; I wish I could reproduce what happened!
In another thread I found that when I copy pasted the makefile contents, the -C after make was using the wrong "-" symbol and I had to re type it. It just so happens that this is the case for the obj-m += ... line above. You need to retype that character to make it valid. This should hopefully be found by anyone following the hello world module tutorial.
I guess you copied the contents of the Makefile from a PDF or some HTML document. The hyphens used are somewhat weird. Just try replacing the hyphens in the makefile; it will work like a charm.
I just ran into this same problem and for me it was caused by changing the default grep options via the GREP_OPTIONS environment variable. I didn't dig into the details, but something in the module build process didn't like my alternate grep output (include file name and line number). Removing the GREP_OPTIONS environment variable fixed things right up.
This happens because when you copy the make file contents from the PDF or any other tutorial websites and use it as it is. While you do a copy-paste, the contents will appear a bit weird in Linux environment. ie; Some special character issues will be there. If you retype the contents in Linux environment and do a make, this should work.
On the machine that fails does your .config have module support disabled?
Try doing "make menuconfig" and make sure module support is enabled.
I can only guess your kernel build environment is botched, because it passes both the theoretical check (the look of the developer) as well as the practical test:
make -C /lib/modules/2.6.36-rc8-32-desktop/build M=/dev/shm modules
make[1]: Entering directory `/usr/src/linux-2.6.36-rc8-32-obj/x86_64/desktop'
make -C ../../../linux-2.6.36-rc8-32 O=/usr/src/linux-2.6.36-rc8-32-obj/x86_64/desktop/. modules
CC [M] /dev/shm/hello.o
Building modules, stage 2.
MODPOST 1 modules
CC /dev/shm/hello.mod.o
LD [M] /dev/shm/hello.ko
make[1]: Leaving directory `/usr/src/linux-2.6.36-rc8-32-obj/x86_64/desktop'
The error mysteriously went away. If anyone has an idea what could cause this. I'd like to know in case there is a next time.
Try to remove modules string from the Makefile:
obj-m = hello.o
KVERSION = $(shell uname -r)
all:
make -C /lib/modules/$(KVERSION)/build M=$(shell pwd) # <--
clean:
make -C /lib/modules/$(KVERSION)/build M=$(shell pwd) clean
I was able to solve this problem by putting the
obj-m += <module name>.o
In a separate file named Kbuild. See Linux/documentation/kbuild/modules.txt for a hint as to why this might work
I had the same problem. Finally, I rebuilt the kernel, rewrote the makefile. It worked finally.
I guess the main reason is because I had M=$(PWD) modules in the following line right after make ARCH=arm...
I solved this problem by correcting Makefile, i.e.:
obj-m := modulename.o
I think it's not about special characters. I couldn't solve even when I manually typed! Then I tried again using kate text editor because previously I used nano and this time it worked like charm by even simple copy and paste. Because of that, I think the issue is the text editor