I'm trying to use a C library called quirc in my C project. So far, I have generated a libquirc.dylib.1.0 by modifying the Makefile which was using Linux .so files.
quirc/helloquirc.c
#include <quirc.h>
#include <stdio.h>
int main() {
struct quirc *qr;
qr = quirc_new();
if (!qr) {
printf("Failed to allocate memory");
}
quirc_destroy(qr);
return 0;
}
I've created the above source file at the root of the repository. I'm using the following command to compile it:
gcc helloquirc.c -lquirc -L. -Ilib -o helloquirc
To my understanding the -l flag specifies the name of the dynamic library, the -L flag specifies the location of the dynamic library, the -I flag specifies the location of the header files, and -o specifies the name of the executable.
When I run this command I get the following error:
ld: library not found for -lquirc
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I changed the Makefile by using this line
.PHONY: libquirc.dylib
libquirc.dylib: libquirc.$(LIB_VERSION).dylib
libquirc.$(LIB_VERSION).dylib: $(LIB_OBJ)
$(CC) -shared -dynamiclib -o $# $(LIB_OBJ) $(LDFLAGS) -lm
and changing other instances of .so.$(LIB_VERSION) to .$(LIB_VERSION).dylib
Something is wrong with the way quirc was built. The correct library name would be something like libquirc.1.0.dylib with a symlink named libquirc.dylib.
It looks like quirc has a handwritten makefile instead of using something sensible like gyp or cmake. Handwritten makefiles are just fine as long as you're not trying to build shared libraries on multiple platforms.
However, if you are just compiling it yourself, you may find things simpler if you just use a static library instead. There is no point in having a shared library if you are not sharing it with anybody (if no other programs are using the same exact copy of libquirc).
Related
Hi I tried doing static library and a shared library with the gnu compiler, here is following code
following is the code for the library
calc_mean.c
double mean(double a, double b){
return (a+b)/2;
}
following is my header file calc_mean.h
double mean(double,double);
Now i started creating static library using following commands
first , calc_mean.c is turned into an object file
gcc -c calc_mean.c -o calc_mean.o
second ,the archiver (ar) is invoked to produce a static
library (named libmean.a) out of the object file calc_mean.o
ar rcs libmean.a calc_mean.o
third, created shared library before that using -fPIC option
created an independant code which is necessary for shared library
gcc -c -fPIC calc_mean.c -o calc_mean.o
now the shared library is created using following command line
gcc -shared -Wl,-soname,libmean.so.1 -o libmean.so.1.0.1 calc_mean.o
finally my main.c file that uses the library is as follows
#include <stdio.h>
#include "calc_mean.h"
int main(int argc, char* argv[]){
double v1,v2,m;
v1 = 5.2;
v2 = 7.9;
m=mean(v1,v2);
printf("The mean of %3.2f and %3.2f is %3.2f\n",v1,v2,m);
return 0;
}
finally I linked the program against static library that generated a statically_linked.exe
gcc -static main.c -L. -lmean -o statically_linked
when dynamically linked, it generated a dynamically_linked.exe with the following command
gcc main.c -o dynamically_linked -L. -lmean
Now when i use the command to execute the dynamically linked program using the following command, Iam getting an error message saying LD_LIBRARY is not recognized as an internal or external command,operable program or batch file
LD_LIBRARY_PATH=.D:\c\project3./dynamically_linked
how can I execute the dynamically linked program?
Your last line suggests that you do all this on windows. But you seem to have followed a step by step guide for linux or another *nix platform.
On windows, a dynamically linked library is in .dll format (not .so) and there's no versioning convention, so the command to create the shared library should look a little different.
Instead of:
gcc -shared -Wl,-soname,libmean.so.1 -o libmean.so.1.0.1 calc_mean.o
do the following on windows:
gcc -shared -Wl,--out-implib,libmean.dll.a -o mean-1.dll calc_mean.o
This creates the library itself named mean-1.dll as well as an import library named libmean.dll.a. The import library (sometimes called .lib instead of .dll.a) on the windows platform is just a stub used during linking of your program, AFAIK MinGW doesn't need it, but other compilers could.
Linking your main program should then work with the same command:
gcc main.c -o dynamically_linked -L. -lmean
And for finding .dll libraries in windows, there is no LD_LIBRARY_PATH -- windows just looks for them in the standard search path, including the directory of the .exe requiring it. IOW, you should be able to just run your program.
When I try to build the following program:
#include <stdio.h>
int main(void)
{
printf("hello world\n");
return 0;
}
On OS X 10.6.4, with the following flags:
gcc -static -o blah blah.c
It returns this:
ld: library not found for -lcrt0.o
collect2: ld returned 1 exit status
Has anyone else encountered this, or is it something that noone else has been affected with yet? Any fixes?
Thanks
This won’t work. From the man page for gcc:
This option will not work on Mac OS X unless all libraries (including libgcc.a) have also been compiled with -static. Since neither a static version of libSystem.dylib nor crt0.o are provided, this option is not useful to most people.
Per Nate's answer, a completely static application is apparently not possible - see also man ld:
-static Produces a mach-o file that does not use the dyld. Only used building the kernel.
The problem in linking with static libraries is that, if both a static and a dynamic version of a library are found in the same directory, the dynamic version will be taken in preference. Three ways of avoiding this are:
Do not attempt to find them via the -L and -l options; instead, specify the full paths, to the libraries you want to use, on the compiler or linker command line.
$ g++ -Wall -Werror -o hi /usr/local/lib/libboost_unit_test_framework.a hi.cpp
Create a separate directory, containing symbolic links to the static libraries, use the -L option to have this directory searched first, and use the -l option to specify the libraries you want to use.
$ g++ -Wall -Werror -L ./staticBoostLib -l boost_unit_test_framework -o hi hi.cpp
Instead of creating a link of the same name in a different directory, create a link of a different name in the same directory, and specify that name in a -l argument.
$ g++ -Wall -Werror -l boost_unit_test_framework_static -o hi hi.cpp
You may also try LLVM LLD linker - I did prebuilt version for my two major OSes - https://github.com/VerKnowSys/Sofin-llds
This one allows me to link for exmple: "Qemu" properly - which is impossible with ld preinstalled by Apple.
And last one is - to build GCC yourself with libstdc++ (don't).
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 made a static library.
This not have error, library file too.
So, I tried use that library.
gcc -o hash_gen main.c -L../ -lhashbundle
Library file exist in that directory ../, library file name is libhashbundle.a.
So, I thought not have problem in this command.
but I tried compile with gcc, but gcc print this error.
main.c:4:10: fatal error: 'hash.h' file not found
#include "hash.h"
^
I don't understand. I made library make, and this is Makefile
all : libhashbundle.a
libhashbundle.a : hash.o
ar rscv libhashbundle.a hash.o
hash.o : src/hash.c
gcc -c src/hash.c
clean:
rm -rf hash.o
I thought this code many times, but I didn't found error.
and this is directory tree
tree
Makefile
libhashbundle.a
|src
|hash.c
|hash.h
|test
|main.c
So, I ask to you.
How could solve this problem?
You only specified a library search path (-L).
If you want a header search path, you need to use -I.
gcc -o hash_gen main.c -I.. -L.. -lhashbundle
The problem is the fact that you're running your build from your "root" directory, not from /src/. So when the compiler sees #include "hash.h" it will try to open the file in the current directory, which will be / rather than /src/ (where the files are).
To fix this, just add your source directory to the include search paths using -Isrc:
gcc -o hash_gen main.c -Isrc -lhashbundle
Note that I omitted -L since the library file is in your current working directory and should be found there anyway.
I am trying to learn the shared library concepts on linux using GCC. So I have created a simple library.
library.c
int foo(void) {
return 10;
}
This is compiled using,
cc -fPIC -g -c library.c
cc -shared -fPIC -Wl,-soname,libmytest.so.1 -o libmytest.so.1.0.1 library.o -lc
It created the file libmytest.so.1.0.1 in the current directory. Now I am writing a client to consume this library in the same directory.
client.c
#include <stdio.h>
extern int foo(void);
int main()
{
int a = foo();
printf("a is %d", a);
return 0;
}
compiling using,
cc client.c -o client -lmytest
but this exits with the message
/usr/bin/ld: cannot find -lmytest
collect2: ld returned 1 exit status
Can anyone help me to find out what I am doing wrong here?
Try using a -L option which is used to add a directory to the list of directories that are searched for the -l option:
cc client.c -L. -o client -lmytest
Assuming the .so is present in the same directory as client.c. If not add suitable path.
The linker on seeing -lmytest looks for libmytest.so but you have a version number appended to it so it does not work. Way to fix this is to create a symlink named libmytest.so pointing to libmytest.so.1.0.1
ln -s libmytest.so.1.0.1 libmytest.so
Alternatively you can use the complete library name on the compile/link line as:
cc client.c ./libmytest.so.1.0.1 -o client
You are missing the -Ldir option.
From the GCC manpage:
-Ldir Add directory dir to the list of directories to be searched for -l.
You'll also need to specify where the shared library is located if you try to run the executable, otherwise the library won't be found. This can be done with:
LD_LIBRARY_PATH=. ./client
Edit:
Thanks but no luck. still the same
error. I even tried with specifying
the full path, but not worked.
I think the linker needs the library to have a .so extension. Try ln -s libmytest.so.1.0.1 libmytest.so and see if it links.
The linker normally searches only the system paths for libraries. Pass -L to gcc in order to specify additional paths to search.