My question: how to tell GCC to search for suitable object files in a directory?
I know I could simply write its path in the command line, but this needs to go in the makefile instead.
I am using Solar's base makefile, which has dependency generation, if that can help.
Civillian wrote:I tried that before starting the thread and it didn't work...
I should know better than to post before breakfast...
-L adds to the path searched for libraries (i.e., things you link in via -l). It doesn't apply here at all, sorry.
A "raw" .o object file (or a .a linker archive) is a different thing. You have to state those directly on the command line, i.e. there is no "search directory" (just like there is no such thing for sources).
Every good solution is obvious once you've found it.
It seems to work if you create an .a file out of all the .o files (just like in your makefile) and then simply feed it to GCC as an "infile" as they call them in the manpage... just to never explain what exactly an "infile" can be...
The linker can take *.o files as input. A *.a file is simply an archive of multiple *.o files, and can be used like any other "infile" to the linker.
The idea behind *.a files is so you don't have to list the individual (and potentially numerous) *.o files; the linker will automatically pick the necessary *.o files from the *.a archive to satisfy any undefined references, and ignore the remaining *.o's.
I.e., *.a is a static (link-time) library, whereas a *.so (or *.dll) is a dynamic (run-time) library. Unless you have a dynamic library loader already implemented, you're stuck with static libraries, which is why I defaulted to them in the make tutorial.
Generally speaking, "man" pages are just for quick reference. If you really want the whole story, you should check out the manual of the tool in question. (Compare the 236 lines of "man make" with the 12,000 lines of the make manual.)
Every good solution is obvious once you've found it.
