I want to compile a small program which has a pretty straight forward makefile, but I seem unable to get it working. Maybe you can help me. The makefile has the following targets:
visca-cli: visca-cli.c libvisca_hl.o
gcc -Wall -o visca-cli visca-cli.c /usr/local/lib/libvisca.so libvisca_hl.o
libvisca_hl.o: libvisca_hl.c
gcc -Wall -c libvisca_hl.c
I can 'make libvisca_hl.o' successfully and create the .o file. But 'make visca-cli' fails with error messages like
libvisca_hl.c:(.text+0x468a): undefined reference to
`VISCA_get_md_disptime'
for every single function defined in libvisca.h (here it's VISCA_get_md_disptime)
Here are the include sections from the various files (ommitting standard libraries):
In visca-cli.c:
#include "libvisca.h"
#include "libvisca_hl.h"
In libvisca_hl.c:
#include "libvisca_hl.h"
In libvisca_hl.h:
#include "libvisca.h"
All includes quoted with "" are present in the local directory where I run make and where all the sourcefiles are. There are no subfolders. So I guess the problem lies with the makefile? Any help appreciated!
The order of libraries and objects on your compilation/link command line matters. In your case, you just need to put the shared object at the end:
gcc -Wall -o visca-cli visca-cli.c libvisca_hl.o /usr/local/lib/libvisca.so
On most systems /usr/local/lib is already part of the standard library search path, so you could simplify further:
gcc -Wall -o visca-cli visca-cli.c libvisca_hl.o -lvisca
Related
Sorry. I think this question would be very easy to you guys.
I have two c files and one h file, I put those two .c files stack.c and main.c and one .h file stack.h inside a folder named "test" at Desktop.
So they are in C:\Users\user\Desktop\test
However when i try to test this code by writing
gcc -c stack.c sq_main.c -l stack.h
It continuously shows "unkown type name ..."
I think the header file is not included into those two .c files.
Actually I wrote the code
#include "stack.h"
Inside stack.c and main.c
Can anyone tell me how to include header file properly?
You are using GCC wrongly. I guess you are on Linux (or on something emulating it like MinGW ...)
If you insist on giving several commands in a terminal, you'll need to run
gcc -Wall -Wextra -g -c stack.c
gcc -Wall -Wextra -g -c sq_main.c
these two commands are building object files stack.o & sq_main.o (from stack.c & the #include-d stack.h, and sq_main.c & the #include-d stack.h, respectively). The options -Wall -Wextra are asking for all warnings and some extra warnings. The -g option asks for debugging information. The -c option asks for compiling only. Assuming that they are enough for your program, you need to link these object files to make an executable:
gcc -g stack.o sq_main.o -o myprogram
You might need to add -Iinclude-directory options to the compiling commands (the first two), and you might need to add -Llibrary-directory and -llibrary-name to the linking command. Order of arguments to gcc matters a lot. You could also add -H to ask the compiler to show which files are included. And GCC has a lot of other options. Read the Invoking GCC chapter of its documentation.
The .o suffix might be .obj on most Windows systems. You might also need myprogram.exe instead of myprogram. I never used Windows so I cannot help more.
In practice, you should use GNU make and write some Makefile; this answer might inspire you.
#include"header.h"
int main(){
function();
return 0;
}
above is simplified form of my code. I implemented function() in header.h file, and put it in the same directory with this code.c file.
I heard that "gcc -c code.c" is "compile but no linking" option, but this code need linking with header.h file. So I guess -c option will flag an error, while it didn't. Though, without -c option it flags an error. Can anyone explain how this -c options works?
Header files have nothing to do with linking. Linking is combining multiple object files and libraries into an executable.
Header files are processed by the compiler, as part of generating an object file. Therefore, gcc -c will process header files.
gcc -c compiles source files without linking.
header files have nothing to do with linking process, they are only used in compilation process to tell compiler the various declaration and function prototypes.
However it is bad practice to implement function in header file, both compilation strategy should work in this case. i.e. gcc with and without c flag
It seems to be a common issue but I can't wrap solve this problem.
I have some .c code that I compile using a makefile. The goal is to create a shared object (.so) so that I can run the C code from R.
Here is my makefile:
obs = R_wrapper.o G.o develop.o utilities.o
CFLAGS = -arch x86_64 -std=gnu99 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/x86_64 -DNDEBUG -I/usr/local/include -fPIC -g -O3 -c
LFLAGS = -arch x86_64 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -O3 -lgsl -lm -lgslcblas
R_wrapper : $(obs)
$gcc $(LFLAGS) $(obs) -o R_wrapper.so
R_wrapper.o : R_wrapper.c constants.h develop.h G.h
$gcc $(CFLAGS) R_wrapper.c
G.o : G.c G.h constants.h utilities.h develop.h
$gcc $(CFLAGS) G.c develop.c
develop.o : develop.c develop.h G.h constants.h
$gcc $(CFLAGS) develop.c
utilities.o : utilities.c develop.h
$gcc $(CFLAGS) utilities.c
It works fine on the computer in my lab but it doesn't work on my personal computer. What causes this issue is these two lines at the beginning of my R_wrapper.c.
#include </opt/local/include/gsl/gsl_randist.h>
#include </opt/local/include/gsl/gsl_rng.h>
I have tried to move these files around and give different paths, put the files in the gal_type.h files in the same directory as my R_wrapper file, I have tried to rename my directories so that the path is more conventional but the OS did not give me the right to rename opt into usr (which probably makes obvious sense). I haven't created the makefile and don't fully get it. I would suppose I'd need to modify the path after the -I argument somewhere in CFLAGS OR LFLAGS.
EDIT 1
I changed R_wrapper.c on my lab computer to get rid of the whole path in #include <...>. Compilation failed as #Beta predicted. Then, I changed my makefile to add -I/opt/local/include/gsl to CFLAGS. I don't know what you mean by Verify that the makefile still works. I tried to compile with my edited makefile on my lab computer and it failed. I then re-edited my makefile changing -I/opt/local/include/gsl to -I/usr/local/include/gsl because on my lab computer the gsl folder is at /usr/local/include/gsl. -I/opt/local/include/gsl is the location of the gsl folder on my computer. So I am stuck here in your procedure.
Edit 2
I moved my gsl folder around my computer trying to include from different paths. And some interesting stuff happen. For example when I put my gsl folder in Users/remi/Documents/Biologie/programing/C/ and write (in CFLAGS)
-I/Users/remi/Documents/Biologie/programing/C/
I get this error:
R_wrapper.c:43:10: fatal error: 'gsl_randist.h' file not found
#include <gsl_randist.h> // goal.
When I write (in CFLAGS)
Users/remi/Documents/Biologie/programing/C/gsl
I get this error message:
"In file included from R_wrapper.c:43: /Users/remi/Documents/Biologie/programing/C/gsl/gsl_randist.h:22:10: fatal error:
'gsl/gsl_rng.h' file not found
#include <gsl/gsl_rng.h>"
Transferring comment to answer
Judging from the message about gsl/gsl_rng.h not being found that is mentioned in Edit 2, you should be writing
#include <gsl/gsl_randist.h>
(with the path prefix of gsl/ before the header name) in your source code. This is a common convention. You then specify in the -I option the name of the directory containing the gsl subdirectory that contains the gsl_*.h headers. In your Edit 2, you say you put the gsl directory into /Users/remi/Documents/Biologie/programing/C/, so you are then correct to use:
-I/Users/remi/Documents/Biologie/programing/C/
on the command line as you tried.
You should read the documentation, and if it says write either of these:
#include <gsl/gsl_randist.h>
#include "gsl/gsl_randist.h"
then that is what you should write in your code, because (as you've discovered the hard way) if you don't, it won't work.
Beta's answer also states
In general it's a bad idea to write paths into the #include statements unless you really have to; it causes just this kind of problem.
I agree, but would state it more strongly:
Do not write complete paths into the #include statements ever.
If you do write them, it radically limits the portability of your code. You can't rely on other people's machines having software installed in the same place as it is installed on your system. If you tried it in open source software, you'd be laughed out of court.
Be wary of people who get cute with ../somedir/header.h too — see What are the benefits of a relative path such as "../include/header.h" for a header?.
I observe that the GNU Scientific Library manual has an example program which starts:
#include <stdio.h>
#include <gsl/gsl_sf_bessel.h>
and the section on Compiling and Linking says:
The library header files are installed in their own gsl directory. You should write any preprocessor include statements with a gsl/ directory prefix thus,
#include <gsl/gsl_math.h>
If the directory is not installed on the standard search path of your compiler you will also need to provide its location to the preprocessor as a command line flag. The default location of the gsl directory is /usr/local/include/gsl.
In general it's a bad idea to write paths into the #include statements unless you really have to; it causes just this kind of problem.
On your lab computer, edit R_wrapper.c:
#include <gsl_randist.h>
#include <gsl_rng.h>
The build should now fail. If so then this verifies that you don't have other versions of these headers floating around, or links to them, or whatever. Confirm that it fails, then back out the change, and confirm that it works again.
Then add -I/opt/local/include/gsl to CFLAGS. Verify that the makefile still works.
Then edit R_wrapper.c again; now the build should succeed.
Decide where you would like to keep these files (gsl_randist.h and gsl_rnd.h) on your personal computer, and modify CFLAGS accordingly on your home version of the makefile.
Once all of that is working perfectly, we can show you how to write one makefile that will work on both machines.
Also, you can improve your makefile rules in other ways, but I must ask one question first:
G.o : G.c G.h constants.h utilities.h develop.h
$gcc $(CFLAGS) G.c develop.c
Does G.o really require develop.c? If so then you should probably reexamine your source files, because this is really unhygienic.
So I have some trouble using shared libraries in combination with GCC.
I'm quite new to this so that's why I came to ask it here. I was unable to find a question on stack overflow that helps me with mine (maybe i overlooked one). But first something about my setup and what I'm trying to accomplish.
So I have these two libraries that are development parallel to each other. One is named liblinkedlist, which contains the linkedlist implementation in C and the other is named libgraph, containing a graph implementation in C. Both are put in the following folder structure:
<root>
+---graph_lib(folder)
+---build(folder)
+---src(folder)
+---makefile(file)
+---linkedlist_lib
+---build(folder)
+---src(folder)
+---makefile(file)
Each src folder contains the source files (linkedlist.h and .c for liblinkedlist and graph.h and .c for libgraph)
In each build folder the .o and .so files created from the header files are stored.
Now the problem is that I want to use the liblinkedlist.so in /linkedlist_lib/build/ in my graph library. While compiling the libraries everything seems to go well. But when I try to use it in combination with including a header file (which is inside the linkedlist library), I get the message that it could not be found.
My compile commands are the following:
For the liblinkedlist:
gcc -fpic -c src/linkedlist.c -o build/linkedlist.o
gcc -shared -o build/liblinkedlist.so build/linkedlist.o
And for the libgraph wich uses the liblinkedlist:
gcc -fpic -c src/libgraph.c -o build/libgraph.o
gcc -fpic -c src/graph.c -o build/graph.o
gcc -L../linkedlist_lib/build/ -o build/libgraph build/libgraph.o build/graph.o -llinkedlist
These are the command and errors I get when using the header file:
gcc -fpic -c src/libgraph.c -o build/libgraph.o
In file included from src/libgraph.c:2:0:
src/graph.h:4:24: fatal error: linkedlist.h: File or folder does not exist
#include "linkedlist.h"
^
compilation terminated.
make: *** [build/libgraph.o] Fout 1
Any ideas on how to fix this problem, am I doing something wrong here?
Thanks in advance
(I am running Linux Ubuntu 9.10, so the extension for an executable is executablefile.out) I am just getting into modular programming (programming with multiple files) in C and I want to know how to compile multiple files in a single makefile. For example, what would be the makefile to compile these files: main.c, dbAdapter.c, dbAdapter.h? (By the way, If you haven't figured it out yet, the main function is in main.c) Also could someone post a link to the documentation of a makefile?
The links posted are all good. For you particular case you can try this. Essentially all Makefiles follow this pattern. Everything else is shortcuts and macros.
program: main.o dbAdapter.o
gcc -o program main.o dbAdapter.o
main.o: main.c dbAdapter.h
gcc -c main.c
dbAdapter.o dbAdapter.c dbAdapter.h
gcc -c dbAdapter.c
The key thing here is that the Makefile looks at rules sequentially and builds as certain items are needed.
It will first look at program and see that to build program, it needs something called main.o and dbAdapter.o.
It will then find main.o. However, to build main.o, it will need main.c and dbAdapter.h (I assume dbAdapter.h is included in main.c).
It will use those sources to build main.o by compiling it using gcc. The -c indicates the we only want to compile.
It does the same thing with dbAdapter.o. When it has those two object files, it is ready to link them. It uses the gcc compiler for this step as well. The -o indicates that we are creating a file called program.
GNU make should be what you're looking for.