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
Related
I would like to know how to link a pgc++ compiled code (blabla.a) with a main code compiled with c++ or g++ GNU compiler.
For the moment linking with default gnu c++ linker gives errors like:
undefined reference to `__pgio_initu'
As the previous person already pointed out, PGI supports G++ name mangling when using the pgc++ command. Judging from this output, I'm guessing that you're linking with g++ rather than pgc++. I've had the most success when using pgc++ as the linker so that it finds the PGI libraries. If that's not an option, you can link an executable with pgc++ -dryrun to get the full link line and past the -L and -l options from there to get the same libraries.
Different C++ compilers use different name-mangling conventions
to generate the names that they expose to the linker, so the member function
name int A::foo(int) will be emitted to to the linker by compiler A as one string
of goobledegook, and by compiler B as quite a different string of goobledegook,
and the linker has no way of knowing they refer to the same function. Hence
you can't link object files produced by different C++ compilers unless they
employ the same name-mangling convention (and quite possibly not even then: name-mangling
is just one aspect of ABI compatibility.)
That being said, according to this document,
PGC++ supported name-mangling compatibility with g++ 3-and-half years ago, provided that PGI C++ compiler was invoked with precisely the command pgc++ or pgcpp --gnu. It may be that the library you are dealing with was not built in that specific way, or perhaps was built with an older PGI C++ compiler.
Anyhow, if g++ compiles the headers of your blabla.a and emits different
symbols from the ones in blabla.a, you can't link g++ code with blabla.a.
You'd need to rebuild blabla.a with g++, which perhaps is not an option.
With IBM's cc compiler there is one option -brtl.
cc-brtl .....
This option does the following:-
-brtl Tells the linkage editor to accept both .so and .a library file types.
I am using gcc compiler now on ubuntu. I want to know what is the corresponding option in gcc to achieve
the same thing?
You don't need that option for gcc. The link editor will accept both so and a files by default, with so files being preferred. You can think of gcc as having the opposite behaviour to IBM's C compiler: The behaviour without any options is as if you provided -brtl to IBM's C compiler, while the option -static turns of dynamic linking (and thus causes gcc to not take so files into consideration), which is as if you didn't specify -brtl to IBM's C compiler.
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.
I was wondering what kinds of libraries used in code are not needed to specify to gcc command? Is /usr/lib/libc.a the only one?
What kinds of libraries are needed to specify to gcc?
Thanks and regards!
You can get an idea of what arguments gcc automatically passes to the linker by using the -dumpspecs switch. For example, on my Windows 7 setup with MinGW using:
gcc -dumpspecs | less
under libgcc section it shows:
*libgcc:
%{mthreads:-lmingwthrd} -lmingw32 %{shared-libgcc:-lgcc_s} -lgcc -lmoldname -lmingwex -lmsvcrt
which suggest those libraries are passed to the ld linker unless I explicitly forbid it with options like nodefaultlibs or nostdlib. Your gcc dumpspec will look different depending on the host-platform, OS and target it was configured to work with.
Edit: To help answer the questions in Tim's comment.
According to the gcc docs the meaning of the spec strings lib and libgcc are as follows:
lib Libraries to include on the command line to the linker
libgcc Decides which GCC support library to pass to the linker
As I understand it, both lib and libgcc are passed to the linker by default. This next part I'm not too sure about, so someone please correct if I'm wrong, if options like nodefaultlib get passed in then only the lib spec string will be applied but the libgcc won't.
I just checked the dumpspec for gcc 4.4.x on Ubuntu running under virtual-box and it appears the libc library gets included under the lib spec string.
*lib:
%{pthread:-lpthread} %{shared:-lc} %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}}
Hope that answers your question.
I am new with using gcc and so I have a couple of questions.
What do the following switches accomplish:
gcc -v -lm -lfftw3 code.c
I know that lfftw3 is an .h file used with code.c but why is it part of the command?
I couldn't find out what -lm does in my search. What does it do?
I think I found out -v causes gcc to display programs invoked by it.
-l specifies a library to include. In this case, you're including the math library (-lm) and the fftw3 library (-lffw3). The library will be somewhere in your library path, possibly /usr/lib, and will be named something like libffw3.so
From GCC's man page:
-v Print (on standard error output) the commands executed to run the
stages of compilation. Also print the version number of the
compiler driver program and of the preprocessor and the compiler
proper.
-l library
Search the library named library when linking. (The second
alternative with the library as a separate argument is only for
POSIX compliance and is not recommended.)
It makes a difference where in the command you write this option;
the linker searches and processes libraries and object files in the
order they are specified. Thus, foo.o -lz bar.o searches library z
after file foo.o but before bar.o. If bar.o refers to functions in
z, those functions may not be loaded.
The linker searches a standard list of directories for the library,
which is actually a file named liblibrary.a. The linker then uses
this file as if it had been specified precisely by name.
The directories searched include several standard system
directories plus any that you specify with -L.
Normally the files found this way are library files---archive files
whose members are object files. The linker handles an archive file
by scanning through it for members which define symbols that have
so far been referenced but not defined. But if the file that is
found is an ordinary object file, it is linked in the usual
fashion. The only difference between using an -l option and
specifying a file name is that -l surrounds library with lib and .a
and searches several directories.
libm is the library that math.h uses, so -lm includes that library. You might want to get a better grasp of the concept of linking. Basically, that switch adds a bunch of compiled code to your program.
-lm links your program with the math library.
-v is the verbose (extra ouput) flag for the compiler.
-lfftw3 links your program with fftw3 library.
You just include headers by using #include "fftw3.h". If you want to actually include the code associated to it, you need to link it. -l is for that. Linking with libraries.
arguments starting with -l specify a library which is linked into the program. Like Pablo Santa Cruz said, -lm is the standard math library, -lfftw3 is a library for fourier transformation.
Try man when you're trying to learn about a command.
From man gcc
-v Print (on standard error output) the commands executed to run the
stages of compilation. Also print the version number of the
com-
piler driver program and of the preprocessor and the compiler
proper.
As Pablo stated, -lm links your math library.
-lfftw3 links in a library used for Fourier transforms. The project page, with more info can be found here:
http://www.fftw.org/
The net gist of all these statements is that they compile your code file into a program, which will be named the default (a.out) and is dependent on function calls from the math and fourier transform libs. The -v statement just helps you keep track of the compilation process and diagnose errors should occur.
In addition to man gcc which should be the first stop for questions about any command, you can also try the almost standard --help option. Even for commands that don't support it, an unsupported option usually causes it to print an error containing usage information that should hint at a similar option. In this case, gcc will display a terse (for gcc, its only about 50 lines long) help summary listing the small number of options that are understood by the gcc program itself rather than passed on to its component programs. After the description of the --help option itself, it lists --target-help and -v --help as ways to get more information about the target architecture and the component programs.
My MinGW GCC 3.4.5 installation generates more than 1200 lines of output from gcc -v --help on Windows XP. I'm pretty sure that doesn't get much smaller in other installations.
It would also be a good idea to read the official manual for GCC. It is also helpful to read the documentation for the linker (ld) and assembler (often gas or just as, but it may be some platform specific assembler as well); aside from a platform-specific assembler, these are documented as part of the binutils collection.
General familiarity with the command line style of Unix tools is also helpful. The idea that a single-character option's value might not be delimited from the option name is a convention that goes back essentially as far as Unix does. The modern convention (promulgated by GNU) that multiple-character option names are introduced by -- instead of just - implies that -lm might be a synonym for -l m (or the pair of options -l -m in some conventions but that happens not to be the case for gcc) but it is probably not a single option named -lm. You will see a similar pattern with the -f options that control specific optimizations or the -W options that control warnings, for example.