I want to make some modifications to the pthread library used for my program. That is why I want to link with my own modified pthread library. I can take the source code in glibc for pthread, modify it and use that for my programs.
Normally you use the flag -pthread for linking with the original pthread library. How do I specify in my makefile to link with my own library.
Just use the -L option to specify the directory where your custom lib is present and use -l option to specify the name of your library.
For Ex:
-L/root/x/mylib -lmypthread
In this case your lib name should libmypthread.so
Refer to http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html for more details.
To ensure that the library is found for loading when you execute your program, do
export LD_LIBRARY_PATH = $(LD_LIBRARY_PATH):/root/x/mylib
-pthread is equivalent to -lpthread -D_REENTRANT with gcc/glibc. You can do the same, but with a different link argument (-lname-of-library).
Don't use -pthread. It is an undocumented GCC option, probably for compatibility with some other (Solaris?) compilers.
The -D_REENTRANT definition which it -pthread enables is completely unnecessary in glibc; none of the headers depend on this macro for thread safety. (The last of such mechanisms were removed from the glibc headers in 1998!) Simply linking in -lpthread is enough to switch glibc functions to thread safe mode, and -lpthread can be substituted with your own library, like the other answer says.
Compile the library in a different name, e.g., libmypthread.so and put it in one of the directories contained in your LD_LIBRARY_PATH environment variable (or add a new directory). Now you can use -lmypthread to link to your library.
Related
I am not sure if the question is framed correctly. But I am using code blocks on a windows machine. I want to use gcc -o myfile myfile.c -lpthread. But in my code blocks I don't have this -lpthread flag(is that called a flag?). So where do I need to add this in code blocks so that when I click build, it will simply call gcc -o myfile myfile.c -lpthread.
-lpthread is a flag to the linker saying to include the library pthread (POSIX threads). I'm not particularly good with code blocks but in the main settings you should be able to find options for configuring the compiler or linker. You need to add the library "pthread" there.
Take a look at this possible duplicate: How do I link to a library with Code::Blocks?
In codeblocks 16.01, you can specify the library you want to link (in this case libpthread.so) via Settings > Compiler... > Linker Settings > Add
Then you need to add the location of libpthread.so via locate libpthread.so
In this case, you may also need to specify -D_REENTRANT compiler flag to tell gcc about necessary headers for thread usage.
I need to include all symbols from a static library. "-force_load" is good when compiling with Xcode. But, for example, when using it under Ubuntu with gcc, "-force_load" is not recognized. I'm looking for alternative options that can be used under other operating systems. Thanks.
The GNU linker's option is called --whole-archive, but while -force_load applies to one library, --whole-archive applies to all libraries after it on the command line. So the usual thing is to do --whole-archive somelib.a --no-whole-archive.
Usually you don't use ld directly but instead invoke it via GCC, in which case you have to tell GCC to pass the options on to the linker: -Wl,--whole-archive,somelib.a,--no-whole-archive
In static linking, how does the linker knows which library file to link the user's compiled object code against? I mean the header only contains the function protoytpes that may be used in the source code, not the library file name.. isn't it?
That's why you provide the linker with a list of libraries to link against!
e.g. for GCC, you might do something like:
gcc my_prog.o -lm -lpthread -o my_prog
Here, the -l flag is used to tell the linker to link against libm and libpthread.
It gets a list of libraries from the command line. The specifics will depend on the OS and the compiler.
I am trying to compile a c program using LLVM and I am having trouble getting some static libraries included. I have successfully compiled those static libraries using LLVM and, for example, libogg.a is present, as is ogg.l.bc.
However, when I try to build the final program, it does not include the static ogg library. I've tried various compiler options with the most notable being:
gcc oggvorbis.c -O3 -Wall -I$OV_DIR/include -l$OV_DIR/lib/libogg.a -l$OV_DIR/lib/libvorbis.a -o test.exe
This results in the following output (directories shortened for brevity):
$OV_DIR/include/vorbis/vorbisfile.h:75: warning: ‘OV_CALLBACKS_DEFAULT’ defined but not used
$OV_DIR/include/vorbis/vorbisfile.h:82: warning: ‘OV_CALLBACKS_NOCLOSE’ defined but not used
$OV_DIR/include/vorbis/vorbisfile.h:89: warning: ‘OV_CALLBACKS_STREAMONLY’ defined but not used
$OV_DIR/include/vorbis/vorbisfile.h:96: warning: ‘OV_CALLBACKS_STREAMONLY_NOCLOSE’ defined but not used
llvm-ld: warning: Cannot find library '$OV_DIR/lib/ogg.l.bc'
llvm-ld: warning: Cannot find library '$OV_DIR/lib/vorbis.l.bc'
WARNING: While resolving call to function 'main' arguments were dropped!
I find this perplexing because $OV_DIR/lib/ogg.l.bc DOES exist, as does vorbis.l.bc and they are both readable (as are their containing directories) by everyone.
Does anyone have any idea with what I am doing wrong?
Thanks,
Matt
As unwind said,
-l is followed by the library name.
For example, in linux library naming conventions,
if a library is named libogg,
-logg will find and choose the *best match in the library directories.
You can add a directory into the list:
-L option is one of the way to add the following folder to the list temporarily.
The environment variable LD_LIBRARY_PATH also affects the list on most of Linux/Unix > with GNU tools.
gcc may find both static and shared library files whose name matches with the requested library name.
For example,
libogg.a
libogg.so
That's why there is a gcc option, -static
-static
On systems that support dynamic linking, this prevents linking
with the shared libraries. On other
systems, this option has no effect.
If you just want to use a shared or static library file - directly, just as an object file,
then give their path without any option, like
gcc oggvorbis.c the_path/libogg.a
I don't think the -l option expects paths. You should split those out, and use the -L option to set the paths, then just use plain library names with -l:
$ gcc oggvorbis.c -O3 -Wall -I$OV_DIR/include -L$OV_DIR/lib -logg -lvorbis -o test.exe
Also note that when used like this, you don't include the "lib" and ".a" parts of the library name.
I am creating a utility which depends on libassuan aside other depends. While these ‘others’ provide shared libraries, libassuan comes with static one only.
libassuan comes with simple libassuan-config tool which is meant to provide CFLAGS & LDFLAGS for the compiler/linker to use. These LDFLAGS refer to the library as -lassuan.
The result of standard call of make is then:
cc -I/usr/include/libmirage -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lmirage -lglib-2.0 -L/usr/lib64 -lassuan -o mirage2iso mirage2iso.c mirage-getopt.o mirage-wrapper.o mirage-password.o
mirage-password.o: In function `mirage_input_password':
mirage-password.c:(.text+0x1f): undefined reference to `assuan_pipe_connect'
mirage-password.c:(.text+0x32): undefined reference to `assuan_strerror'
collect2: ld returned 1 exit status
make: *** [mirage2iso] Error 1
(I've just started writing this unit and that's why there aren't more errors)
So, if I understand the result correctly, gcc doesn't want to link the app to libassuan.a.
Using -static here will cause gcc to prefer static libraries over shared which is unindented. I've seen solution suggesting using something like that:
-Wl,-Bstatic -lassuan -Wl,-Bdynamic
but I don't think it would be a portable one.
I think the best solution would be to provide full path to the static library file but libassuan-config doesn't provide much of help (all I can get from it is -L/usr/lib64 -lassuan).
Maybe I should just try to create the static library path by ‘parsing’ returned LDFLAGS and using -L for the directory name and -l for the library name — and then hoping that in all cases libassuan-config will return it like that.
What do you think about that? Is there any good, simple and portable solution to resolve the issue?
PS. Please note that although I'm referring to gcc here, I would like to use something that will work fine with other compilers.
PS2. One additional question: if package does install static library only, returning such LDFLAGS instead of full .la path can be considered as a bug?
gcc will link to libassuan.a if it doesn't find libassuan.so
It's probably the order symbols are looked up in the static library when you link. The order matters.
)
Assuming gcc can find libassuan.a and it actually provides the functions the linker complains about, try:
cc -I/usr/include/libmirage -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lmirage -lglib-2.0 -L/usr/lib64 -o mirage2iso mirage2iso.c mirage-getopt.o mirage-wrapper.o mirage-password.o -lassuan
Since you say libassuan is under /usr/lib64 it's probably a 64 bit library, are your app and the other libraries 64 bit as well ?
Compiler's command-line options are not a portable thing. There's no standard for it. Every compiler uses its own and several can merely informally agree to comply with each other in command-line format. The most portable way for your linking is to use libassuan-config, of course. I think, it can generate not only flags for gcc, but for other compilers as well. If it can't, then no portable way exists, I suppose (other than CMake or something on higher level).
The command line to cc you shown is totally correct. If you have a static library libassuan.la and path to it is supplied to -L option, then the compiler does link against it. You can see it from its output: has it not found the static library, would it complain with error message like "can't find -lassuan". I
Moreover, if no libassuan.so is found, then compiler links against your library statically, even if you haven't used -Wl,-Bstatic stuff or -static flag.
Your problem may be in persistence of several versions of libassuan in your system. Other that that, I don't see any errors in what you've provided.
Which directory is libassuan.a in
I think the first error is not gcc doesn't want to link the app to libassuan.a it is more gcc does not know where libassuan.a . You need to pass gcc a -L parameter giving the path to libassuan.a .
e.g.
-L /home/path