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.
Related
I've been working on a module in C (under Linux) that requires another module (headers are in other directories).
My problem is that when I compile the code with my Makefile, the gcc compiler tells me that some headers aren't found.
gcc -c render.c
So I include the directories to find the header but here, gcc tries to find the "main" function which does not exist: it is a module...
gcc /opt/vc/include -c render.c
So I would like to know how is it possible to compile a module (output in module.o) that requires other modules?
Here are my files:
render.c:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include "render.h"
int width,height;
int loop,counter;
int initRender(void(*setup)(void),void(*draw)(void),void(*end)(void))
{
init(&width, &height);
loop = -1;
counter = 0;
setup();
while(loop==-1)
{
Start(width, height);
draw();
End();
counter++;
}
end();
finish();
exit(0);
return 0;
}
render.h:
#include "VG/openvg.h"
#include "VG/vgu.h"
#include "fontinfo.h"
#include "shapes.h"
#ifndef RENDER_H_
#define RENDER_H_
extern int width,height;
extern int loop,counter;
int initRender(void(*setup)(void),void(*draw)(void),void(*end)(void));
#endif
Makefile:
INCLUDEFLAGS=-I/opt/vc/include -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads -IopenVG
LIBFLAGS=-L/opt/vc/lib -lGLESv2 -lEGL -lbcm_host -lpthread -ljpeg -LopenVG
NEEDED= openVG/libshapes.o openVG/oglinit.o
all: render
render.o: render.c
gcc -Wall -g $(INCLUDEFLAGS) -c render.c
You probably want
gcc -Wall -g -I/opt/vc/include -c render.c
this will produce a render.o object file.
Please take time to read the documentation about invoking GCC. In particular, check what every option -Wall, -g, -I and -c means. IMHO the first two are very important.
Later, you probably want to link all your object files into an executable, with some external libraries. Perhaps you want something like
gcc -g -Wall -L/opt/vc/lib render.o main.o -lvc -o myprogram
(you really want the -Wall and -g options; IMHO you need to be an expert to dare avoiding them; once you have debugged your program and want to benchmark it, add -O2 for optimizations)
But surely, you want other options.
Notice that order of arguments to gcc matters a lot
Of course, you should learn about GNU make and you need to use it. See this and that examples. You might use make --trace (with recent make) or remake to debug your Makefile (which is not good). You should also run once make -p to understand more the builtin rules of make.
Perhaps you want a library, then read the Program Library HowTo.
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;
}
I am writing a graphics program in C/C++ using OpenGL. I have a bunch of .c files and right now, I am trying to call a function from main.cpp in assignment1gui.c. The teacher has given me a file with the compile code. It looks like this:
OBJS = assignment1gui.o shadertools.o main.o
TARGET = ass1
CXX = gcc
DBFLAGS = -O0 -g3 -ggdb3 -fno-inline
WFLAGS = -Wall -ansi
GLFLAGS = `pkg-config --cflags gtk+-2.0`
LGLFLAGS = `pkg-config --libs gtk+-2.0` -lGL -lGLEW -lGLU -lglut
CXXFLAGS = $(WFLAGS) $(DFLAGS) $(GLFLAGS)
LDFLAGS = -export-dynamic -lXext -lX11 $(LGLFLAGS)
all: $(TARGET)
clean:
rm -f $(OBJS) $(TARGET)
.SUFFIXES: .cc
.cc.o:
$(CXX) -c $(CXXFLAGS) $<
.c.o:
$(CXX) -c $(CXXFLAGS) $<
$(TARGET): $(OBJS)
$(CXX) -o $(TARGET) $(OBJS) $(LDFLAGS)
The function I am trying to call is "drawPloygonLine()". I have declared this in "assignment1gui.h", and the definition, as I mentioned earlier, is in main.cpp.
From all the help on the Internet, I realized that there must some problem with the compile code. But I am not sure. Could someone please help me out?
Sorry I left out this part earlier. The errors I am getting are:
assignment1gui.o: In function `on_btn_color_color_set':
assignment1gui.c:(.text+0x1c): undefined reference to `drawPolygonLine'
assignment1gui.o: In function `on_rb_tool_line_toggled':
assignment1gui.c:(.text+0x8b): undefined reference to `drawPolygonLine'
assignment1gui.o: In function `on_rb_tool_circle_toggled':
assignment1gui.c:(.text+0xfc): undefined reference to `drawPolygonLine'
assignment1gui.o: In function `on_rb_tool_rect_toggled':
assignment1gui.c:(.text+0x16d): undefined reference to `drawPolygonLine'
assignment1gui.o: In function `on_rb_tool_edit_toggled':
assignment1gui.c:(.text+0x24a): undefined reference to `drawPolygonLine'
collect2: ld returned 1 exit status
make: *** [ass1] Error 1
The C/C++ files I have in the folder are main.cpp, assignment1gui.c and shadertools.c. I also have two header files- assignment1gui.h and shadertools.h. As I have mentioned earlier, I used the assignment1gui.h file to declare the new function "drawPolygonLine();"
Addition:
The declaration of the "drawPolygonLine();" is now in "main.h" and it looks like this:
#ifndef MAIN_H
#define MAIN_H
extern void drawPolygonLine();
#endif /* MAIN_H */
Both main.cpp and assignment1gui.c have "#include "main.h"" at their beginning. The definition of drawPolygonLine() is:
void drawPolygonLine()
{
if(option[opCount-1]==4 && drawn==false)
{
vCount++;
vertex[vCount].x=A;
vertex[vCount].y=B;
lines=lines+2;
vCount++;
vertex[vCount].x=polyX;
vertex[vCount].y=polyY;
clicks=0;
drawn=true;
}
}
All the variables used in the function are global in main.cpp.
An example of how I am calling drawPolygonLine(); in assignment1gui.c is in this function:
void on_btn_color_color_set(GtkColorButton *colorbutton, gpointer user_data)
{
drawPolygonLine();
GdkColor color;
gtk_color_button_get_color(colorbutton, &color);
printf("Color set rgb=(%i,%i,%i)\n",color.red,color.green,color.blue);
}
I hope this makes it clear.
The problem is that main.cpp isn't understood by this make file, since it only has rules for .cc or .c files. I suspect that main.o isn't being built - or, more likely, since you're getting as far as a failed compile, there is another file called main.c or main.cc which IS included in your program, but doesn't have drawPolygonLine() defined in it.
To solve this:
Remove or rename any existing main.c or main.cc files.
If your program is actually a C program, then change the filename to main.c
If your program is a C++ program, you could try changing the extension to .cc, but I suspect you'll then run in to problems since you're using gcc rather than g++. In this case, I'd also change:
CXX = gcc
to
CXX = g++
Remember that although a lot of C code is also valid C++ code, there are many subtle differences - and the best practices are very different in each language. For this reason, it's best to treat C and C++ as different languages.
If this doesn't fix it:
Check that the function signature of drawPolygonLine() declared in your header file is the same as the way it's defined in your main file. Check that these declarations match with the way you've called it.
Check that the files that call drawPolygonLine() have #include "assignment1gui.h" at the top
Check that drawPolygonLine() isn't declared as static (static functions aren't visible outside their translation unit - so the linker won't see them when compiling two output files together)
Also, it's good practice to have the function declaration in the header file corresponding to the source file it's defined in - so if you want to call a function in main.c from assignment.c, you would usually put the declaration in main.h, and #include it at the top of assignment.c. This won't be the cause of the problem that you're having, but it's good practice to get used to.
I have a question. I was wondering if you could re-compile code with another piece of code. For example (theoretical):
main.c:
#include <stdio.h>
void showme();
int main()
{
showme();
}
void showme()
{
fprintf(stderr, "errtest, show me");
}
Compile this file to main. (So the main is compiled)
After this I want to add a piece of code.
addthis.c:
void test()
{
test();
}
Now I want to use the (compiled) main and re-compile it with addthis.c.
When running it (./mainWithAddthis) should show the print 2 times.
I hope I explained it clear. Anybody an idea?
You need a forward declaration for your void test() like you have one for the void showme(). Compile each .c file with -c (compile only) option:
gcc -c addthis.c -o addthis.o
gcc -c main.c -o main.o
Then link the two object files with:
gcc main.o addthis.o -o main
Then enjoy ./main :-)
Your first code will not compile since there's not definition of test();.
As I understand, you want to take the compiled main and add it with the code generated on addthis.o to create a 2nd application named mainWithAddthis. This is not possible!
You are either confused or trying to do some hardcore trick.
Building an executable is a two step process.
For every source file you specify (in your project/makefile), your compiler will build an object file
For every object file you specify (in your project/makefile), your linker will link them together and make your executable
One way to re-compile would be simply to re-build your entire project. You'd get more or less the same result.
But it sounds like what you want to do is recompile only the source file, addthis.c, then re-link the old version of main.o (the object file compiled for main.c) with the new version of addthis.o. How to do this is completely dependent on the compiler and build system you use.
Also, that solution will only work if you have main.o, addthis.c, and have the exact same compiler binaries/install, and compiler flags used to generate main.o. If this is all on your box, then you're probably okay.
If you only have the files addthis.c and main.exe, then no there is no portable way to do what you want.
You can't do what you are talking about after the fact without some hardcore time with a hex editor.
However, if you plan ahead and build it into your software, you can use dynamic loading to achieve the same effect, which is how a lot of software provides plugin functionality. Check out glib modules for a common way to do this in C.
main.c
void f();
int main()
{
f();
return 0;
}
addon1.c
#include <stdio.h>
void f()
{
printf("I am the ONE.\n");
}
addon2.c
#include <stdio.h>
void f()
{
printf("I am the TWO.\n");
}
Compilation
gcc -c main.c -o main.o
gcc -c addon1.c -o addon1.o
gcc -c addon2.c -o addon2.o
gcc main.o addon1.o -o main1
gcc main.o addon2.o -o main2
You will have ./main1 and ./main2 programs which will print ...ONE. and ...TWO..
I already know the differences between a header file and a library. However, when I'm writing my makefile, I have some difficulties on deciding if I should put something as a dependency of the file or just at the linking rule.
For example: I have 2 simple files:
main.c:
#include <stdio.h>
main(){
printf("this is the sine or 90");
sinus(90);
}
and func.c:
#include <math.h>
sinus(int num){
return sin(num);
}
and my makefile is:
main: main.o func.o
gcc main.o func.o -lm -o main
func.o: func.c
main.o: main.c
Well, my question is why this makefile works and this one doesn't:
main: main.o func.o
gcc main.o func.o -lm -o main
func.o: func.c math.h
main.o: main.c
You don't need to make func.o depend on math.h as that file is very unlikely to change.
Regarding the error you get if you do is because you don't explicitly specify how make should compile the file so it tries to deduce how to compile it and it only works in simple cases. I'm not sure exactly how make does it but I think it just does gcc -o target.o -c <your deps>.
Because make is looking for a file "math.h" in the current directory and trying to do cc func.c math.h to produce func.o
Problem is that you don't know exactly how Makefile is resolved after using implicit rules - definitely there's one which causes problems you have. (maybe try to compile math.h, or math.h is not found etc.. (you didn't posted errors you have so we can only speculate).
I would advice you to disable implicit rules by calling make with "-r" and do everything explicitly - this way you will learn more as you'll know how makefile works instead of knowing how to write makefiles which works under some circumstances.
More on implicit rules: Make documentation - Implicit rules
More on make Make documentation