Implicit Declaration Of Function - c

I've just organized my code by using headers, but just as I've done this, I got a warning that turned into an error when linking.
I have a code(use of a function that is inside a header) in test.c that is like this:
#include "test1.h"
/* Some code */
main()
{
Testing();
}
And my test1.h header is like this:
void Testing();
void print(int, int, int, const char*);
And at test1.c
void Testing()
{
print(0xF9, 27, 5, "\xC9\\xBB");
}
void print(int colour, int x, int y, const char *string)
{
volatile char *video=(volatile char*)0xB8000 + y*160 + x*2;
while(*string != 0)
{
*video=*string;
string++;
video++;
*video=colour;
video++;
}
}
When I try to compile the code, I got this:
ubuntu#eeepc:~/Development/Test$ gcc -o test.o -c test.c -Wall -Wextra -nostdlib -nostartfiles -nodefaultlibs
test.c: In function ‘main’:
test.c:11: warning: implicit declaration of function ‘Testing’
ubuntu#eeepc:~/Development/Test$
At the time it's just a simple warning, but when I try to link it...
ubuntu#eeepc:~/Development/Test$ ld -T linker.ld -o kernel.bin loader.o test.o
test.o: In function main':
test.c:(.text+0xfc): undefined reference toTesting'
What I need to do?

Edit: To reflect the OP's question I have struck out some lines of my answer despite being upvoted...
Why is kernel.c flagged up in the compiler, even though you don't have it mentioned here? Am I missing something...
gcc -o test.o -c test.c -Wall -Wextra -nostdlib -nostartfiles -nodefaultlibs
kernel.c: In function ‘main’:
kernel.c:11: warning: implicit declaration of function ‘Testing’
ubuntu#eeepc:~/Development/Test$
maybe you need to do it this way somewhere in your header file as I'm judging you want kernel to access this function:
extern void Testing();
And, take out all your functions and place them in a separate .c file, they should not be in there in the first place... for example:
Testing.c
/* all your functions here */
Testing.h
/* Only global, external variables and function prototypes */
Hope this helps,
Best regards,
Tom.

I can't recreate your problem. This works as expected when I try to compile your code on an Ubuntu machine (Which based on your paste, I assume you're using.)
Are you sure the #include is happening correctly?
Try using -E instead of -c to see what the whole code the compiler is trying to compile looks like.

Somewhat of a shot in the dark here, since my C is a bit rusty, but does C allow you to put function bodies in a header? I don't recall that it does. Try moving the definition of Testing() and print() into a .c file? You could also try compiling as C++ as see if that fixes it, if you don't need/want C.

You included test.h into main.c, while your declarations, according to what your wrote, are in test1.h. Note the 1 in the name.
In addition to that, you are compiling test.c and linking test.o, while in reality the name of your file is test1.c. Again, note the 1 in the name.
Edit: Now you edited the name of the file included into main.c. After the edit it is safe to assert that most of the symptoms you describe are not possble with the current versions of the files. Re-verify what you are doing, post updated disgnostic information and/or post real code.
Still, you compiler and linker lines are referring to old file names.

i donno whats causing this , but i had this problem just now .
try to delete the .h file and put the declarations of the functions on the top of .c file itself .
in this case , delete the test1.h and put the declarations of functions of test1.c in test1.c.
and include test1.c in test.c
you wont get that warning message any more , nor the following linking errors .

Related

Undefined reference to functions included by a lib

I have one lib which contains a file (called Util.c down here), and i'm trying to use some funtions defined in this file to compile a little prog. I'm already using others functions from the lib, but the ones of this particular file always give me back an "Undefined Reference". What's really weird is: the others functions from the lib does use functions from Util.c, and that's working well. It's just that...i can't use them directly.
I'll try to give you a clear view of the things here:
Util.c
void foo (void *var){
print ("in Foo!");
}
void *bar (int var){
print ("in bar!");
}
Util.h:
#ifndef UTIL_DEFINED
#define UTIL_DEFINED
void foo(void *var)
void *bar(int var)
#endif
libobj.c:
#include "Util.c"
// #include "a lot of other files.c"
MyFile.c:
#include "Util.h"
// #include "others headers from the lib which functions are working well"
int main(){
//here i use the lib's function without a prob, except for the ones coming from Util.c, namely foo and bar. For example:
int *var;
//Say that LibFunc is another function from the lib, but not from Util.c.
//Libfunc make a call to foo, and it's working well.
Libfunc(var);
//However, here i try to use foo or bar, and i get the undefined reference!
foo(var);
bar(var);
}
The Makefile is a big thing, but if i search only for the parts related to the lib, it looks like it:
Lib Makefile
default: $(LIB)
$(LIB): $(LIBOBJ)
-$(RM) "$#"
$(DLLD) -o "$#" $(DLLDFLAGS) "$(LIBOBJ)"
$(LIBOBJ): libobj.c $(LIBSRC) $(LIBINC)
$(CC) -c $(LOTOFFLAGS) libobj.c -o "$#"
LIBSRC: libobj.c\
aBunchOfOtherFiles.c
LIBINC: Util.h\
ABunchOfHeadersFiles.h
LIBOBJ=$(LIBNAME)dll.o
LIB=$(LIBNAME).dll
CC= gcc
DLLD = gcc -shared -fprofile-arcs -ftest-coverage -fprofile-generate
DLLDFLAGS = -fPIC
LOTOFFLAGS = -Wall -pedantic -Wno-long-long -Wno-unused-function -g -g3 -ggdb -std=c99 --coverage -fprofile-arcs -ftests-coverage -fprofile-generate -Wl,--allow-multiple-definition -fPIC $(IFLAGS)
#IFLAGS include all headers files, as well as some info concerning Lib version, OS, PROC, etc... not so important here.
IFLAGS = -I$(FOLDERS) -DWINDOWS
FOLDERS= MyFolders
LIBNAME = MyLibName
RM= del
And finally, my makefile looks like it:
My Makefile
default: $(PROG_EXE)
$(PROG_EXE) : $(LIB) $(PROG_OBJ)
$(CC) $(SOMEFLAGS) $(PROG_OBJ) "$(LIB)" -o "$#"
$(PROG_OBJ) : MyFile.c $(LIBINC)
$(CC) -c $(SOMEFLAGS) -$(IFLAGS) MyFile.c -o "$#"
LIB = $(LIBNAME).dll
LIBINC = Util.h\
ABunchOfHeadersFiles.h
PROG_EXE= MyProg
PROG_OBJ = MyProg.o
CC= gcc
SOMFLAGS = -Wall -std=c99 -pedantic -g -g3 - ggb -fprofile-arcs -ftests-coverage
#IFLAGS basically include all folders containing source code and headers. Also gives some D, such as OS, PROC or the lib version. Not really important for my prob.
IFLAGS = -I$(FOLDERS) -DWINDOWS
FOLDERS = MyFolders
LIBNAME = MyLibName
Note that i didn't made any of that. I'm just supposed to make it works...
I've tried to get all the flags (think i got them all). Some of them are only for the use of gcov, others just to include the good folders and files. I've already checked: Util.c and Util.h are correctly included in thoses. BTW, when i compil MyProg, i don't have the "file not found" error on Util.h, so it is found.
Also, i've seen that foo is supposed to get a void* and is actually given a int*. But i don't think it's the problem here, since when i compile MyProg using directly Util.c, without trying to get it from the lib, it works well.
So i really think that, somehow, my prog can't find the functions in the lib. But it does found the header well, and it does found others functions from the lib well, and those functions use the ones froms Util.c, so i just don't get it :'(
Plus, i've tried to compile the lib WITHOUT Util.c, just to be sure that the lib really uses it. Then i got the same "undefined reference", so it seems that the lib correctly includes Util.c
PS: i'm on windows 32bits, if that is of any use...
I think the mistake comes from libobj.c file:
#include Util.c
The quotation marks are missing:
#include "Util.c"
In General we #include the .h and not the .c.
I've found a way to make it works, even if i still can't understand the problem.
It seems that, in Windows using Mingw, you have to add __declspec( dllexport ) in front of each function you wanna use from outside of the dll.
So, if i change my Util.c this way:
`__declspec( dllexport ) void foo (void *var){
print ("in Foo!");
}
`__declspec( dllexport ) void *bar (int var){
print ("in bar!");
}
I think this lib is somehow set so that it has "publics" and "privates" functions; until now i was just using the public ones, and the ones inside Util.c are private. It's the only explanation i see, even if i had no idea how to makes function privates or public.

Why I got "clang: error: cannot specify -o when generating multiple output files"?

I am a newbie in C. I have two simple source code files f1.c and f2.c.
f1.c looks like:
#include <stdio.h>
#include "f.h"
void f1(void) {
// some code ...
}
function f2() in f2.c relies on f1() in f1.c.
#include <stdio.h>
#include "f.h"
void f2(void) {
f1();
}
f1.c and f2.c share a same header f.h,
void f1(void);
void f2(void);
There are no main() access, I just want to compile these two file into a .o file without linker (using -c option),
gcc -c f1.c f2.c -o f2.o
then I got,
clang: error: cannot specify -o when generating multiple output files
but when I mentioned only f2.c, it works well,
gcc -c f2.c -o f2.o
So what's the problem? Thanks!
You should look into the compilation process for C. The first stage is compiling the .c source code into .o object files. The .c files do not need to see the other .c files; they are accepting as fact what you've told them about the existence of external functions. It's not until the linker comes in that it really needs to see the function because the implementation details don't matter to your .c file, just the interface, which you've presumably given it in the header.
What you can do, if you like, is drop the -o flag specifying the output file you want to create. Just compile with
gcc -c f1.c f2.c
and it will know to create f1.o and f2.o which will be able to link against each other when the time comes that you do want to go through with the linking process.
I am curious, however, what your intentions may be for wanting to compile these without linking. I only ask as you refer to yourself as a newbie, so I am wondering if maybe there is an end goal you have in mind and perhaps aren't asking the right question.

What is wrong with my header files?

I've just completed a school assignment and I'm having a problem testing my code because I keep getting the following output after running make packetize (it's a makefile the professor gave us)
cc packetize.c -o packetize
/tmp/ccJJyqF6.o: In function `block_to_packet':
packetize.c:(.text+0xb1): undefined reference to `crc_message'
collect2: ld returned 1 exit status
make: *** [packetize] Error 1
block_to_packet is defined in a file called packetize.c, crc_message is defined in crc16.c (both of which contain an #include "data.h" line). data.h also has the function heading for crc_message in it All of these files are in the same directory. I've been trying to compile them for the past hour and a half and have searched Google endlessly with no avail. It has something to do with linking I've read, my instructor has not taught this and so I don't know how to compile these files to test their outputs. Can anyone let me know what's wrong?
Your header files are absolutely OK. What you have there is a linker error: The compilation of packetize.c ran without problems, but then you're trying to link an executable file packetize (since you did not give the -c option which states "compile to object file"). And the executable would need the compiled code from crc16.c as well.
Either you have to give all sources on the compiler line:
cc packetize.c crc16.c -o myApp
Or you have to compile into individual object files, eventually linked together:
cc -c packetize.c -o packetize.o
cc -c crc16.c -o crc16.o
cc packetize.o crc16.o -o myApp
The former is what you'd do in a one-shot command line, the latter is what a Makefile usually does. (Because you do not need to recompile crc16.c if all you did was modify packetize.c. In large projects, recompiles can take significant amounts of time.)
Edit:
Tutorial time. Take note of the existence / absence of -c options in the command lines given.
Consider:
// foo.c
int foo()
{
return 42;
}
A source file defining the function foo().
// foo.h
int foo();
A header file declaring the function foo().
// main.c
#include "foo.h"
int main()
{
return foo();
}
A source file referencing foo().
In the file main.c, the include makes the compiler aware that, eventually, somewhere, there will be a definition of the function foo() declared in foo.h. All the compiler needs to know at this point is that the function will exist, that it takes no arguments, and that it returns int. That is enough to compile the source to object code:
cc -c main.c -o main.o
However, it is not enough to actually compile an executable:
cc main.c -o testproc # fail of compile-source-to-exe
ld main.o -o testproc # fail of link-object-to-exe
The compiler was promised (by the declaration) that a definition of foo() will exist, and that was enough for the compiler.
The linker however (implicitly run by cc in the first example) needs that definition. The executable needs to execute the function foo(), but it is nowhere to be found in main.c. The reference to foo() cannot be resolved. "Unresolved reference error".
You need to either compile both source files in one go...
cc foo.c main.c -o testproc # compile-source-to-exe
...or compile foo.c as well and provide the linker with both object files so it can resolve all references:
cc -c foo.c -o foo.o
ld foo.o main.o -o testproc # link-objects-to-exe
Post Scriptum: Calling ld directly as pictured above most likely will not work just like that. Linking needs a couple of additional parameters, which cc adds implicitly -- the C runtime support, the standard C library, stuff like that. I did not give those parameters in the examples above as they would confuse the matter and are beyond the scope of the question.
You have to compile crc16.c as well and link these two object files to build the binary. Otherwise packetize.c, from where crc_message() is being called, has no knowledge of it.
Try using
cc packetize.c crc16.c -o packetize
Your call crc_message() from packetize.c would just be fine.
As Totland writes crc_message is defined in crc16.c; which means that packetize.c can't see the definition, no matter how many shared headers they have. You do not have a compile error but an error from the linker.
If you compile your c files first to object files and then link everything to an executable it will work.

C Linking Error: undefined reference to 'main'

I have read the other answers on this topic, and unfortunately they have not helped me. I am attempting to link several c programs together, and I am getting an error in response:
$ gcc -o runexp.o scd.o data_proc.o -lm -fopenmp
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
make: * [runexp] Error 1
I have exactly one main function and it is in runexp. The form is
int main(void) {
...;
return 0;
}
Any thoughts on why I might get this error? Thanks!
You should provide output file name after -o option. In your case runexp.o is treated as output file name, not input object file and thus your main function is undefined.
You're not including the C file that contains main() when compiling, so the linker isn't seeing it.
You need to add it:
$ gcc -o runexp runexp.c scd.o data_proc.o -lm -fopenmp
You are overwriting your object file runexp.o by running this command :
gcc -o runexp.o scd.o data_proc.o -lm -fopenmp
In fact, the -o is for the output file.
You need to run :
gcc -o runexp.out runexp.o scd.o data_proc.o -lm -fopenmp
runexp.out will be you binary file.
Generally you compile most .c files in the following way:
gcc foo.c -o foo. It might vary depending on what #includes you used or if you have any external .h files. Generally, when you have a C file, it looks somewhat like the following:
#include <stdio.h>
/* any other includes, prototypes, struct delcarations... */
int main(){
*/ code */
}
When I get an 'undefined reference to main', it usually means that I have a .c file that does not have int main() in the file. If you first learned java, this is an understandable manner of confusion since in Java, your code usually looks like the following:
//any import statements you have
public class Foo{
int main(){}
}
I would advise looking to see if you have int main() at the top.

Why I need C header files?

It is a dumb question, I admit. Code will explain it better. Got these files:
hello.c:
#include <stdio.h>
void hello(char * s)
{
printf("hello, %s\n", s);
}
main.c:
int main()
{
hello("world!");
return 0;
}
makefile:
test : main.o hello.o
gcc -o test main.o hello.o
main.o : main.c
gcc -c main.c
hello.o : hello.c
gcc -c hello.c
.PHONY : clean
clean :
-rm test
-rm main.o
-rm hello.o
I can just "make" and "./test" it and it works.
Shouldn't I need to include something like hello.h in main.c just so the compiler knows the function prototype?
I didn't even include hello.c anywhere and it just works! How come main.c knows about the hello function?
If that works, when do I need .h files? I am new to C programming but I thought this concept was easy to grasp, now I am completely confused.
If you use the -Wall flag (and one should always use it, along with -Werror -Wextra), then you'd get the following message:
main.c: In function 'main':
main.c:3: warning: implicit declaration of function 'hello'
And the compiler effectively "guesses" what to do, which can lead to disaster in many circumstances.
Correctly using header files avoids this sort of warning.
You do not need header files; instead, your functions need prototypes. When you call hello passing it "world", C figures out that you are calling a one-argument function taking char*, and does everything right. This will not work, however, if the function takes a float, and you decide to ass it an int (try it, it is very instructive). For reasons of backward compatibility C will let you call functions without prototypes, but it is dangerous. For example, in case of your call of hello, the compiler thinks that you are calling a function returning an int. Technically, you are invoking undefined behavior, so your program works by accident.
Headers happen to provide the most convenient way to supply prototypes, but you can supply them in the code itself, like this:
void hello(char*);
int main()
{
hello("world!");
return 0;
}

Resources