Re: automatic linking links too many files
James Coleman wrote: The intent of the default rule is to make it easy to handle object files or libs I think. So it makes sense that for you the file is assumed to be an object file and is passed to the link line. For anything other than very simple cases you will make your own rules. Thanks for the advice. I was not reporting this behavior as erroneous, but warning that it differs significantly from the documentation (Each kind of file automatically made into `.o' object files will be automatically linked). In fact, there is this neat workaround: -Makefile contents $(phony foo): textfile executable: $(phony foo) - but that was not my point. Additional remark: An executable depending from a text file may actually be needed in real life: e.g. in order to use the Gtk+ component GtkBuilder, the executable must read a `foo.ui' xml file which should be built from a `foo.glade' file. --federico poloni ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: automatic linking links too many files
On Mon, May 25, 2009 at 5:56 AM, Federico Poloni f.pol...@sns.it wrote: ... Thanks for the advice. I was not reporting this behavior as erroneous, but warning that it differs significantly from the documentation (Each kind of file automatically made into `.o' object files will be automatically linked). Yes, the behavior doesn't match the docs. I guess the question now is which should be changed. The current behavior is better than what is documented for at least two cases---archive files and linker scripts---though the latter is quite obscure. Fixing the docs to say that the default rule will treat all prerequisites of the executable as linker inputs seems better to me. In fact, there is this neat workaround: -Makefile contents $(phony foo): textfile executable: $(phony foo) - but that was not my point. Umm, what do you think the above actually does? There's no built-in function $(phony), so all you've done is removed 'textfile' from 'executable's prerequisite list. If you change textfile, executable will *not* be rebuilt! Additional remark: An executable depending from a text file may actually be needed in real life: e.g. in order to use the Gtk+ component GtkBuilder, the executable must read a `foo.ui' xml file which should be built from a `foo.glade' file. Can you briefly enumerate the actual commands that need to be invoked in such a setup, indicating what files are the input and output files in each step (if it's not obvious)? I ask, because I suspect you're mixing *build-time* dependencies and *run-time* dependencies. In a makefile, the prerequisites for a target, executable or otherwise, should only be those needed at build-time. If foo.ui is read at runtime by the executable itself, then the foo.ui is *NOT* a prerequisite of the executable. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: automatic linking links too many files
On Fri, May 22, 2009 at 8:04 AM, James Coleman jam...@dspsrv.com wrote: ... 4. I notice that adding a static library doesn't get picked up by a default rule. I'm not going to dig further into this. My syntax for libs might be wrong, makefile.lib: executable: othercfile.o staticlibrary.a staticlibrary.a: yetanothercfile.o $ make -f makefile.lib g++ -c -o othercfile.o othercfile.cpp g++ -c -o yetanothercfile.o yetanothercfile.cpp g++ executable.cpp othercfile.o staticlibrary.a -o executable g++: staticlibrary.a: No such file or directory make: *** [executable] Error 1 Almost. To trigger the built-in library archiving rules you need this: executable: othercfile.o staticlibrary.a staticlibrary.a: staticlibrary.a(yetanothercfile.o) $ make g++-c -o othercfile.o othercfile.cpp g++-c -o yetanothercfile.o yetanothercfile.cpp ar rv staticlibrary.a yetanothercfile.o ar: creating staticlibrary.a a - yetanothercfile.o g++ executable.cpp othercfile.o staticlibrary.a -o executable rm yetanothercfile.o $ However: 1) the syntax is annoyingly redundant, using the .a name twice 2) it unnecessarily rebuilds the archive's symbol table after each addition 3) it breaks if you have multiple files in the archive and use parallel make (If your system's ar doesn't rebuild the symbol-table by default, the (2) doesn't apply, but your archives don't have symbol-tables!) Much better is to write a command that handles all the changed archive members in one go: staticlibrary.a: yetanothercfile.o yacf.o $(AR) $(ARFLAGS) $@ $? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
automatic linking links too many files
Hello everyone,
According to GNU Make documentation,
Linking a single object file
n is made automatically from n.o by running the linker (usually
called ld) via the C compiler. The precise command used is `$(CC)
$(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)'.
This rule does the right thing for a simple program with only one
source file. It will also do the right thing if there are multiple
object files (presumably coming from various other source files), one
of which has a name matching that of the executable file.
[...]
Each kind of file automatically made into `.o' object files will be
automatically linked by using the compiler (`$(CC)', `$(FC)' or
`$(PC)'; the C compiler `$(CC)' is used to assemble `.s' files)
without the `-c' option. This could be done by using the `.o' object
files as intermediates, but it is faster to do the compiling and
linking in one step, so that's how it's done.
But when I try to make this simple example with three files:
`Makefile' contains:
executable: textfile
`executable.cpp' contains:
int main(){
return 0;
}
`textfile' contains:
asdasdasdas
the output of `make' is
g++ executable.cpp textfile -o executable
/usr/bin/ld:textfile: file format not recognized; treating as linker script
/usr/bin/ld:textfile:1: Error: syntax error
collect2: Error: ld returned 1 exit status
make: *** [executable] Error 1
That is, make tries to pass textfile to the linker even if it is not a
kind of file automatically made into `.o' object files.
Is this a bug or am I missing something?
The command `make --version' on my machine returns
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for x86_64-pc-linux-gnu
Regards,
--
Federico Poloni
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: automatic linking links too many files
Hello, The intent of the default rule is to make it easy to handle object files or libs I think. So it makes sense that for you the file is assumed to be an object file and is passed to the link line. For anything other than very simple cases you will make your own rules. 1. Do you actually want to make a dependancy on a file/files like textfile? I think in that case it would be easiest to define your own rule. You may have a point that there is something unexpected in make. I don't see what rule would match textfile and treat it as an object file. But I'm not sure. 2. If you just want to use default rule and have one c file yhen you want maybe a very simple makefile containing: all: executable $ make -f makefile.all g++ executable.cpp -o executable 3. If you have more than one c file you add a dependancy on the other c files object files: executable: othercfile.o $ make -f makefile.other g++-c -o othercfile.o othercfile.cpp g++ executable.cpp othercfile.o -o executable 4. I notice that adding a static library doesn't get picked up by a default rule. I'm not going to dig further into this. My syntax for libs might be wrong, makefile.lib: executable: othercfile.o staticlibrary.a staticlibrary.a: yetanothercfile.o $ make -f makefile.lib g++-c -o othercfile.o othercfile.cpp g++-c -o yetanothercfile.o yetanothercfile.cpp g++ executable.cpp othercfile.o staticlibrary.a -o executable g++: staticlibrary.a: No such file or directory make: *** [executable] Error 1 Just thinking a bit out loud, hope this is of some use to you also. James. Federico Poloni wrote: `Makefile' contains: executable: textfile the output of `make' is g++ executable.cpp textfile -o executable ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
