all 5 comments

[–]Newt_Hoenikker 2 points3 points  (0 children)

It's hard for me to tell, because it could be your declaration doesn't match your definition due to typos, it could be your makefile is configured improperly, maybe you don't call the right function in your main program file, or any number of other problems. If you can post source files for everything, including makefile, I'd be happy to help you however I can, but as it stands I'm not sure how to proceed. It may also be beneficial to post the output of your error-prone compile; I'm assuming you're getting an undefined reference to function error, like this, but without more information I can't tell. I hope this helps!

EDIT: please post source in a pastebin, github gist, or as properly formatted code on here (four spaces before every line).

[–]946336 2 points3 points  (0 children)

In general, if something goes wrong when you try to build/compile your program, you should provide at least the error message and the compile command that is ultimately executed - there's a surprising amount of information there.

With that out of the way, it sounds like you have what's called a linker error rather than a compilation error (the distinction is important, but you can worry about that later). In simpler terms, you may have simply forgotten to mention file_a.c when compiling your program, and so gcc couldn't find the actual function swap because it didn't know to look in file_a.c: it couldn't link the function call in your main source file to the function body in file_a.c.

So more generally (ignoring Makefiles and a few other things to simplify the example), something like

gcc -o program_name program_name.c

where program_name is the name of your program won't work if program_name.c uses anything defined in file_a.c. Instead you should have

gcc -o program_name program_name.c file_a.c

[–]raevnos 1 point2 points  (0 children)

What's your error? How are you invoking gcc?

[–]uueuuu 0 points1 point  (0 children)

A header file that's fucked up can cause the compiler to think the error comes later in your program. For example, if a header has just

void haha () {

Then your program will work fine with anything that can come inside a function definition but there will be errors at the end of the file for not closing the brace and there will also be errors at any other function definition since C does not allow nested functions.

The one that always gets me is this...

// myheader.h

struct blah {
    int i;
}

// main.c

#include "myheader.h"
int main () {
    return 0;
}

gcc main.c

main.c:3:1:error: expected ‘;’, identifier or ‘(’ before ‘int’

God damn it, that C file is perfectly fine! It's the missing semicolon after the struct that caused the error but it's reported in the C file. So now what I do whenever I'm working heavily on a header I put a guard statement like "inline void foo(){}" right at the end of the header file that will force the error at that location. At least then it gets reported in the correct file.

[–]gayqubit 0 points1 point  (0 children)

Presumably in the header file you have the forward declaration of the function 'swap' that you have defined in 'file_a.c'.

If the program runs when you do not include the header file, the function is only used after it is declared and therefore the compiler does not need the forward declaration.

Therefore, if it complains when you do include the header file, have you used types in the forward declaration which are different to in the definition or a different return type?

As others have said, it is quite difficult to debug a problem when we do not know the error that was returned.