I want to be able to turn all the *.asm files in a folder to *.o files. For example, if I have header.asm and main.asm, I want header.o and main.o. Nasm can only assemble 1 input file to 1 output file.
I have tried this:
%.o : %.asm
nasm -f elf64 $(patsubst %.o,%.asm,$#) -o $#
along with multiple other things but to no success.
Somewhere you have to tell make what files you want to assemble. A pattern rule is just a template for how to build a .o from a .asm. It's not an instruction that says "go find all .asm files and turn them into .o files". It's a template that says, IF you want to build a .o file, and you can find a .asm file, then here's how you can turn the latter into the former.
So, you need a pattern rule to describe how to build things:
%.o : %.asm
nasm -f elf64 $< -o $#
then you also need a list of the things you want to build; say:
all: foo.o bar.o baz.o
(since you haven't told us anything about the names of the .asm files you want to build I just used random names).
Related
I'm trying to understand how to handle header file dependencies in Make rules. Let me give you a specific example.
I'm building application called myap using GNU Make. It consists of various *.h and *.c files.
Directory inc/ contains defs.h and util.h header files.
Directory src/ contains main.c, cmd.c and win.c files.
Directory obj/ contains all generated object files.
I have multiple applications that need different build options. So I don't want to rely on any implicit rules and would like to specify my own rules for all object files, etc.
I would like to specify the following rules:
Object files depend on specific *.h and *.c files. If any of them change, all object files must be regenerated. However, even though *.h files are part of the prerequisites list, I don't want to pass them to the compiler. I only want to compile *.c files.
Executable myapp depends on specific *.o files. If any of them change, executable file must be regenerated.
So far, the following Makefile with a static pattern rule seems to work correctly:
myapp_inc := inc/defs.h inc/util.h
myapp_src := src/main.c src/cmd.c src/win.c
myapp_obj := $(patsubst src/%.c,obj/%.o,$(myapp_src))
myapp_bin := obj/myapp
.PHONY: all
all:
# Create obj/main.o obj/cmd.o and obj/win.o from various *.c files
# If any *.h files in $(myapp_inc) list change, all objects are regenerated.
# If any *.c files in $(myapp_src) list change, all objects are regenerated.
$(myapp_obj): obj/%.o: src/%.c $(myapp_inc) $(myapp_src)
gcc -c -o $# $<
# Create obj/myapp from various *.o files
# If any *.o files in $(myapp_obj) list change, executable is regenerated.
$(myapp_bin): $(myapp_obj)
gcc -o $# $^
all: $(myapp_bin)
.PHONY: clean
clean:
rm -f obj/*
I don't quite understand how Make rules should be written correctly in order to handle such use case. Is the above static pattern rule, the only way that works correctly?
Specifically, I have tried the following combinations, as given in various simple examples on the Internet, and they all failed for various reasons.
This rule causes $< to always pass the name of the first prerequisite, which doesn't work with multiple *.c files:
$(myapp_obj): $(myapp_src) $(myapp_inc)
gcc -c -o $# $<
$ make
gcc -c -o obj/main.o src/main.c
gcc -c -o obj/cmd.o src/main.c
gcc -c -o obj/win.o src/main.c
gcc -o obj/myapp obj/main.o obj/cmd.o obj/win.o
/bin/ld: obj/cmd.o: in function `main':
main.c:(.text+0x0): multiple definition of `main'; obj/main.o:main.c:(.text+0x0): first defined here
/bin/ld: obj/win.o: in function `main':
main.c:(.text+0x0): multiple definition of `main'; obj/main.o:main.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:18: obj/myapp] Error 1
This rule causes $^ to always pass the names of all prerequisites, which fails:
$(myapp_obj): $(myapp_src) $(myapp_inc)
gcc -c -o $# $^
$ make
gcc -c -o obj/main.o src/main.c src/cmd.c src/win.c inc/defs.h inc/util.h
gcc: fatal error: cannot specify ‘-o’ with ‘-c’, ‘-S’ or ‘-E’ with multiple files
compilation terminated.
make: *** [Makefile:13: obj/main.o] Error 1
Now I understand the difference between $< and $^ variables, but a lot of documentation is not clear on how they should be used when dealing with a list of multiple *.c and *.h files as prerequisites.
What are the recommended usage pattern for this?
Why is it that when using $< only *.c files get passed to the recipe, but not *.h files? Is Make doing some internal filtering? Is this documented anywhere? Is it possible to modify this behavior for custom suffixes?
Is the above static pattern rule, the only way to make objects depend on *.h and *.c files, but exclude *.h files during compilation?
I don't understand the goal of trying to avoid implicit rules. But in any event, it doesn't matter to the recipe you write whether the rule was implicit or explicit: the same automatic variables are set either way. The $< automatic variable is always the first prerequisite, so if you write your rules such that the first prerequisite is the appropriate .c file then you can always use $< in your recipe to mean the .c file and no other files. All the following will work:
%.o : %.c $(headers)
gcc -c -o $# $<
foo.o: foo.c $(headers)
gcc -c -o $# $<
foo.o : %.o : %.c $(headers)
gcc -c -o $# $<
%.o : %.c
gcc -c -o $# $<
$(srcs) : $(headers)
and others.
Does this mean that all of the prerequisites apply, but only those that match the pattern get passed to the recipe?
I don't understand the question, really. The value of variables and the expansion of the recipe happens only AFTER make has decided to run the rule and is not really related (except for some special automatic variables like $?). Once make has decided that the target is out of date and the recipe needs to be run, it will assign the appropriate automatic variables, expand the recipe, then pass the recipe to the shell to be run.
The automatic variables are assigned as described in the manual: $# is the target, $< is the first prerequisite, $^ is all the prerequisites, etc.
ETA
You still haven't really explained why you don't want to use static pattern rules. They are a perfectly fine and reasonable way to do things.
If you explain what you don't like about static pattern rules, or what you wish you could do differently, then we can probably suggest alternatives that meet those requirements.
Specifically, I have tried the following combinations, as given in various simple examples on the Internet,
$(myapp_obj): $(myapp_src) $(myapp_inc)
Wherever you found this as a recommended example on the Internet, you should immediately delete from any bookmarks as that site doesn't know anything about make.
We see this paradigm at least once a week on SO. I've never really understand why people think it will work: I guess they think make is much more "magical" than it is. Consider, what does the above expand to? Suppose myapp_obj contained foo.o bar.o biz.o and myapp_src contained foo.c bar.c biz.c and myapp_inc contained foo.h bar.h, then make sees:
foo.o bar.o biz.o: foo.c bar.c biz.c foo.h bar.h
I suppose some people think make will intuit that the ".o" files should somehow match up with the ".c" files and will generate a bunch of rules that make that true. That's not what make does. The above line is exactly identical to writing this:
foo.o: foo.c bar.c biz.c foo.h bar.h
bar.o: foo.c bar.c biz.c foo.h bar.h
biz.o: foo.c bar.c biz.c foo.h bar.h
That is, if you have multiple targets make creates one copy of the rule for each target, with the same prerequisites and recipe.
This is obviously not what you want, and that's why none of the examples that try to do things this way can ever work properly.
Why is it that when using $< only *.c files get passed to the recipe, but not *.h files? Is Make doing some internal filtering? Is this documented anywhere? Is it possible to modify this behavior for custom suffixes?
None of that is the case. As I described above, the $< expands to the first prerequisite. That's all. It doesn't matter whether the first prerequisite is a .c file, a .h file, or some other file; whatever it is, $< will be that value. If you write your rule as:
foo.o : foo.c foo.h ; $(CC) -c -o $# $<
then your compiler will be invoked with foo.c. If you write your rule as:
foo.o : foo.h foo.c ; $(CC) -c -o $# $<
then your compiler will be invoked with foo.h. There's no magic here.
I am having a doubt on how to use dependencies in my GNU makefile.
Consider the following make file:
// Building all my dependency files
$(OUTDIR)/%.dep: %.c
$(DPP) $(CPPFLAGS) $(DPPFLAGS) $(#:dep=o) $< $#
Now, I have these dependency files containing lists or "pointer" to files/dependencies.
I then want to create my object files based on those dependencies (when they change).
Can I do the following thing:
$(OUTDIR)/%.o $(OUTDIR)/%.orc: %.c $(OUTDIR)/%.dep
$(AS) $(COMMONFLAGS) $(CPPFLAGS) $(ASFLAGS) -o $# $<
Does that not however mean that I will be rebuilding my objects only when my *.dep files actually change (not the files listed within those dependency files).
Is that the correct way of doing it? If not, what is?
I feel like I am not using/understanding how these dependency files are being interpreted by the tools.
The dependency files are themselves in makefile format, and is input to make, not gcc. To use them, you will need to include them in your makefile (ignoring the file if it hasn't been created yet):
-include $(wildcard *.dep)
The only caveat is that it will then build the dep files whenever it needs to build anything, including a "make clean", so you need to make the include conditional on the target:
ifneq ($(MAKECMDGOALS),clean)
-include $(wildcard *.dep)
endif
SOURCE=a.c b.c c.c
ASM=$(patsubst %.c,%.s, $(SOURCE))
all:%.o
gcc -o test $^
$(ASM):%.c
gcc -S -o $# $<
%.o:%.s
gcc -c -o$# $<
I want to generate assembly code (.s) first, then compile the assembly code to object (.o), then link them.
But it seems above makefile code does not work. What is the correct code?
When asking questions, does not work is never very useful... if it worked you probably wouldn't be asking a question! :-) Instead you should always show the command you ran and the output you received (or at least the failing part of the output if it's long). Please cut and paste the actual text rather than paraphrasing messages. Also, including the version of the make program you're using (make --version) and the platform you're running on is often helpful.
Luckily this time we can figure out the problem without this information:
This:
$(ASM):%.c
gcc -S -o $# $<
where ASM is a.s b.s c.s, is not a pattern rule because the targets don't contain a pattern character %. That means the prerequisite %.c is not treated as a pattern, but as an actual file name, literally %.c which obviously doesn't exist.
Similarly, this:
all: %.o
has the same problem: all is a target, so this depends on the literal file named %.o which doesn't exist, and can't be created.
Also as a general rule every recipe that creates a target must create the actual target you told make it would, so this all rule is wrong because the target name is all but the recipe creates the target test.
Finally, it's a very bad idea to name your program test because test is a common UNIX program and a shell built-in, so if you run test it won't do the right thing (if you run ./test it will work).
You want to have all depend on the program you want to build, say mytest, and mytest should depend on the actual .o files:
all: mytest
mytest: $(SOURCE:.c=.o)
gcc -o $# $^
Next, you need to define a pattern rule that knows how to create an assembly file from a source file:
%.s : %.c
gcc -S -o $# $<
That, along with your other pattern rules, is all you need: make will figure it all out from that.
Finally, make has a built-in rule that tells it how to build object files directly from source files. It's best to get rid of this to force make to use your rules; add this to your makefile to delete it:
%.o : %.c
To perform an experiment I want to modify the assembly code of the OpenWRT Project (by inserting NOPs between the regular, meaningful code).
Thous I need to create the assembly files (.s files) by compiling with gcc's -S flag in the first run, execute a shell script modifying the assembly files and call the linker in the third step to create the executable binaries. Beside step 2, is there a way to accomplish steps 1 & 3 by an appropriate make file modification/configuration, i.e. create one make file for compiling (creating .s files) and another to conduct linking?
Thanks for enlightenment &
Happy a new year! :)
use this syntax:
target [target...] : [dependent ....]
[ command ...]
example:
%.S: %.c
$(CC) -S $# -c $<
%.o: %.S
$(CC) -o $# -c $<
which means to build the target foo.o make should build foo.S and for foo.S build foo.c
$# means target name
$< means targets first dependency
I am trying to compile a library file using other library files. I am using the following line in my makefile to create gameobject.o:
lib/gameobject.o: src/gameobject.cpp src/vector.hpp lib/objectevent.o lib/sprite.o
g++ $^ -c -o $# $(SFML_FLAGS)
All the dependencies comile correctly, but I get the following error when it tries to compile gameobject.o:
g++: fatal error: cannot specify -o with -c, -S or -E with multiple files
I'm still a bit new to using make/separating compilation, so I'm not quite sure what I should do. Do I just have to compile it without setting an output? Do I have to compile gameobject.o without using any of my other .o files? If that's true, wouldn't compile times get pretty big for large objects if you can't compile libraries with other libraries? Or am I just reading this error completely wrong?
You're not building a library file here. A .o file is an object file. Typically there is one object file per source file. When you use the compiler's -c option, it takes a single source file and compiles it into a single object file. You cannot add other object files into an existing object file, so adding both .o and .cpp files into the same compiler line with -c is not going to work.
If you want to create a library, that would be something like libfoo.a (the "a" here stands for "archive"). If you want to create an executable you can do that as well.
You need to be more clear about exactly what result you want before we can describe how to get it.
I had the same problem after I combined some projects of a solution to a single one. I find out there was tow .cpp files with same names and after I did rename one of them It solved.
You can create only one object .o file from one source file.
If you are using makefile to build the project. Make sure you are doing $< instead of $^
# Correct one
%.o: %.cpp
$(CPP) $(CFLAGS) -c -o $# $<
# InCorrect one
%.o: %.cpp
$(CPP) $(CFLAGS) -c -o $# $^