Linker issue! Can we make a linker troubleshooting guide here?

[abcdefghijklmnopqrstuvwxy]

I guess this isn't C++ specific, yet I'll post in the C++ section because i'm working with gcc (that comes with dev-c++) and C++. A recurring issue that has haunted me ever since I first learned that almost everything you need is already programmed in C++, all you need to do is download the right library, is getting things set up so I can use the code in the new libraries.

In IDE's like Dev-C++ you have to specify linker options in a special location. Let's not worry about that. Instead, let us focus on how you come up with the linker option you need to add? I'm sure that hard core programmers don't sit around playing with header files and .cpp files, adding include statements all over the place, and other such experiments just to get some new code they downloaded working. But what I just described is an example of me, and I'm sure, many others.

Lets say I download a folder containing "functions.h" and "functions.cpp". I DON'T want to put these files in the same directory as all my subsequent programs that require it. These files are useful and will be used time and time again, after all... So I put functions.h in my compiler's "include" directory and can't figure out where to put functions.cpp so I just throw it in with functions.h in the include directory and I make code as follows:

code:

include<functions.h> int main() {     functions::myfunction();     return 0; }

I attempt to compile and the only thing that comes up is a linker error. There is no readme. I'm completely at a loss...

And to ensure completeness... lets talk about what linking actually is. I don't even really know. I have an idea, but it's probably wrong.

Does anyone know what I'm talking about? What I just described really really frustrates me, and since there is no readme, my guess is that it's not too difficult to figure out.

[abcdefghijklmnopqrstuvwxy]

After conducting more research I've learned that the actual libraries are stored in binary. So if you needed a library called lwdhv.a you would write -lwdhv.a in the command line...
I managed to resolve my linker issue this way, but I'm still a little confused. For instance, how would I go about creating my own binary library? And what is the point of explicitly declaring the libraries you need in the command line? Why can't the header file specify which libraries it needs? That whole thing doesn't make sense to me...

[md]

If you've got multiple files then it's time to learn Makefiles. Makefiles tell the compiler what to compile, and then what to link together to make an executable.

Say I've got a project with main.cpp, cool_stuff.hpp, cool_stuff.cpp, functions.hpp and functions.cpp. functions.cpp includes functions.hpp, likewise cool_stuff.cpp includes cool_stuff.hpp. main.cpp includes both hpp files.

To build the program you'd need to compile functions.cpp into an object (.o) and cool_stuff.cpp into an object, and of course main.cpp into an object. then you need to link the objects together to make an executable.

non-makefile

So, you start with functions.cpp:

code:

g++ -c -Wall functions.cpp -o functions.o

Here -c means compile only, -Wall is to tell the compiler to give all warnings, and -o tells the compiler what to save the output as.

cool_stuff.cpp and main are pretty much the same:

code:

g++ -c -Wall cool_stuff.cpp -o cool_stuff.o g++ -c -Wall main.cpp -o main.o

Next you link the objects together to make your executable:

code:

g++ functions.o cool_stuff.o main.o -o app.exec

And that's it! It's kinda a pain though because you need to type out all the commands (and there can easily be a lot more); plus you need to recompile the object for each file you modify before you can build your app again. It just becomes a nightmare.

makefiles!
Makefiles simplify the process immensely. They are read by a program called make; which will then recompile anything that's been changed since the last time you built your app. For out example program here is one possible makefile:

makefile:

app.exec : main.o functions.o cool_stuff.o     g++ main.o functions.o cool_stuff.o -o app.exec main.o : main.cpp functions.hpp cool_stuff.hpp     g++ main.cpp -c -Wall -o main.o functions.o : functions.cpp functions.hpp     g++ functions.cpp -c -Wall -o functions.o cool_stuff.o : cool_stuff.cpp cool_stuff.hpp     g++ cool_stuff.cpp -c -Wall -o cool_stuff.o

This requires a little bit of explaining, but at first glance it's not that complex at all. The first line tells make that app.exec depends on main.o, functions.o and cool_stuff.o. The next line (indented with a tab character) tells make how to build app.exec. After that are similar structures telling make what each of main.o, functions.o and cool_stuff.o depend on and how to build those.

When you run make from the command line it'll read your makefile, and then start building. Let's say that you have never built your app before. Make will see that app.exec depends on main.o, functions.o and cool_stuff.o and then check to see if they are up to date. Since none of them exist then make will run the rules required to build them. Then make will run the rule required to build app.exec. And all you needed to do is type "make".

Let's say you then modify cool_stuff.cpp. When you type make it will check the dependencies for app.exec and find that cool_stuff.o is older then cool_stuff.cpp. Then it will rebuild cool_stuff.cpp but not anything else before rebuilding app.exec. Make is smart enough to no that it doesn't need to rebuild things that haven't changed.


How does this relate to your linker question? Well #include is for including header files (.h .hpp) and not code files (.c .cpp). Headers are supposed to include function headers and class interfaces, basically things that aren't actual code. That way when you include them in your source file the compiler knows that they exist and how to call them; and it assumes that you will later provide the actual code to run things. If you include the implementation then the compiler will see multiple copies of the same function (function name really; they could be different functions) and won't know what to do. Hence the errors. To avoid that you must either compile each source file separately and then link them together; or compile them all at once and link at the same time (I didn't cover this as it's SLOW with lots of files). Makefiles basically handle compiling things for you; so all you need to do is type "make".

[abcdefghijklmnopqrstuvwxy]

thanks for that explanation md. I've always had to run make files in linux but i never knew exactly what they did. Is there a make for windows? And two questions... so if linking is including object files of all the implementions of the classes you need

code:

g++ functions.o cool_stuff.o main.o -o app.exec

then what is the -l (lower case L) parameter do? Is that another form of linking?

And secondly what are the .a files in the lib folder and how do they differ from the object files?

[md]

-l is for linking to a library. A library is a not the same as an object file IIRC. Unfortunately I do not know how to compile a library off hand; fortunately it doesn't matter. You almost never need to know how to build a library unless you are explicitly writing one.

[edit] yes, there is almost certainly make for windows, and at this very moment I am ot sure about your other questions.

[OneOffDriveByPoster]

Try (or Google):

man ld
man ar
man ranlib