It's said that linux loader is /usr/bin/ld, but usually we use gcc/g++ to link libraries and executables, we barely use "ld".
The last time I used "ld" manually was when I was learning linux assembly, the only way to generate executable is to ld a .o file to generate executable directly without any library.
My question is, is gcc/g++ containing some function wrappers of "ld", because raw "ld" is too difficult to use? Or we should never use "ld" explicitly for c/c++ program linking, because of blablabla?
gcc supplies a few default options to ld.
ld doesn't know anything about C++, or any other language. ld has no idea what libraries your code needs to link with. If you try to link your compiled C++ code with ld directly, it'll bail out on you, since ld, by itself, has no idea where it can find libstdc++, gcc's C++ runtime library. Do you use strings? vectors? Most of that is template code that gets compiled as part of your object module. But there are a still few precompiled bits, in libstdc++, that need to be linked with.
When you give your compiled code to gcc to link, gcc will be courteous enough to pass all your files along to ld, and tell ld which libraries, in addition to any ones you explicitly specify.
You can link with ld directly, if you want to, as long as you specify the same libraries and link option gcc uses. But why would you want to do that? Just use gcc to link your gcc-compiled code.
You shouldn't attempt to directly use ld to link a C++ program because you need to know the implementation detail of where the static part of the C++ runtime library is located. g++ knows these implementation details, such as where to find the file libstdc++.a. If you tried to use ld directly, you would have to supply all these "missing" static libraries.
My question is, is gcc/g++ containing some function wrappers of "ld"
That's right.
because raw "ld" is too difficult to use?
Well, not really; you could use it yourself without too much trouble, but it's convenient to manage the entire build process through a single executable, with a single suite of flags, and often with a single command.
It's also likely that you'd have to provide absolute paths to some runtime libraries (e.g. libstdc++.a) yourself if you bypassed the wrapper (though I haven't tested this).
Or we should never use "ld" explicitly for c/c++ program linking, because of blablabla?
You're free to do so if you want. The only reason people might raise their eyebrows is to ask why you're not doing it in the conventional manner. If you have a good reason to invoke ld directly, rather than going through g++ and passing through any linker flags that way, then go right ahead!
Related
I need to link my SO against libbfd, for the purpose of having human-readable backtraces.
Static linking against libbfd.a fails, because it's not compiled with -fPIC, so as I understand, it can participate in executable only.
Though linking against libbfd.so also gives some troubles.
I need to compile on both Ubuntu-14.04 and Debian Wheezy 7.8
And they have non-intersecting sets of binutils versions. In particular, Ubuntu has 2.24, and Debian has 2.22 and 2.25. And the problem is, gcc doesn't want to take symlink's name libbfd.so to reference it, and uses SONAME instead. So i end with either libbfd-2.24-system.so or libbfd-2.25-system.so in dependencies.
For now I see several approaches:
There's some hidden flag which allows to override SONAME during linking. This is the preferred path
I have no way other than compile libbfd by hand. I would evade this as much as possible.
Manual dlopen+dlsym for everything I need.
I read answer gcc link shared library against symbolic link, but it suggests to change SONAME I'm not able to do.
Any suggestions?
Thanks.
EDIT: it seems that virtually all static libs in Ubuntu repos are not position-independent. Can't guess why. With the inability to override SONAME it makes things much more complicated.
Not sure whether i understand your (4 years old problem) correctly, but having similar problems with libbfd, I found this solution:
Using the linker flag -lbfd seems to work.
It is a linker flag that specifies g++ to link against libbfd.
My full command was g++ loader.cc -lbfd.
At least for me, errors at link-time a la "unknown function" are solved.
I've used zlib for ages and never thought about the fact that it is named slightly unconventionally. While most libraries on Linux follow the naming convention of lib<name>.so for shared objects and lib<name>.a for archives, zlib is named zlib.so/zlib.a. My question is: how does gcc/ld know to look for zlib.so when I use -lz as a link flag?
I understand that for linking, gcc invokes ld, which searches for libraries in certain default paths and any path specified with -L, and it appends the lib and .so or .a. parts as necessary. Oddly, gcc's manual page for linking options only mentions that the linker can find archives; there is no mention of the .so extension. The man page for ld at least mentions both extensions, but still only mentions searching by prepending lib to the specified library name. How does ld know to add the lib after the z for zlib? I've never seen this happen to another library.
gcc has several different methods for linking libraries, shared or static. If you specify -lz, gcc is going to look for libz.so (possibly with some version bits between the libz and the .so, but the important part is the file name will start with libz and end with .so), or for libz.a (again, possibly with version info) if you are compiling statically, or as a fallback if the shared library does not exist. If you specify -lzlib it will look for libzlib.so (which is not the standard name - the package is often named zlib, but the library itself is libz). Another way of linking would be to not use the -l<lib> option, and just specify /path/to/zlib.so or -L /path/to zlib.so (or zlib.a if you want). In this case, the library doesn't have to have the lib prefix, but you would have to explicitly provide any version info, unless provisions are made for a symbolic link or something similar to provide the literal name zlib.so.
Applications can also load shared libraries at runtime via dlopen() and it's other associated functions, in which case the library can also be named whatever you want it to be (this doesn't work for static libraries, of course).
So, if the library you are looking at is actually called zlib.so, then it is not being found by gcc ... -lz, unless it just happens to be a symbolic link to libz.so (or vice versa, in which case gcc is really just using libz.so, which happens to have the same content as your zlib.so). However gcc might be using it if the build process explicitly names the library in the link stage (not using -l<lib>) or if your application loads it via dlopen() (but in that case, it's not really linked to your program - it's just loaded at run time).
I use gcc more than any other compiler, so I will shape my example with this compiler suite, but i have experienced this problem with almost all the suite that i have tried like gcc, mingw, clang and msvc.
gcc offers this flags:
-l you write the name foo, gcc will find a corrisponding library named libfoo
-L you append the path where the libs lives and gcc tries to match the required libraries to the ones that it finds in that path
-rpath basically a pool of different path for the same lib so the executable is "smart" enough to look for alternatives if he needs one.
the problem is big for me, no one of this solves my problem and each one of this flags suffer the same problem: ambiguity.
if I just want to link a library that i know there is no way to do this without including a dose of ambiguity in the best case scenario, what i want is:
linking 1 specific library only, and only the 1 that I specify with a precise name and path
avoid auto-completion mechanism like the one on the name given to -l because my libs are named foo.so not libfoo.so
relative path for the linked libs
only consider the explicitly given set of libraries, no other automation of any kind should be involved, no pool of libs, no search-paths, no nothing else, I prefer list of errors instead of an executable linked to a random library
I often deal with different libs in different releases, they often share the same name for historical and compatibility reasons, it's a nightmare compiling and linking with gcc because I never got the one that I want linked to my executable.
Thanks.
The easiest way to do this is to simply specify the library.
gcc -o test test.o /path/my_library.so /path/to_other_library.a
The obvious downside to this approach if of course that if you move that library then your application won't work anymore but since you state that you have the libraries at fixed locations it should work in your case.
Some context:
My program uses libary libfl.a (flex library).
I compile it under linux:
gcc lex.yy.c -lfl
I have mingw compiler installed i586-mingw32msvc-gcc (simple 'hello world' stuff compiles without problem)
I use ubuntu (probably does not matter)
I want to compile under linux for windows (produce binary .exe file which would be usable on windows)
My problem and questions:
When I try compiling my program
i586-mingw32msvc-gcc lex.yy.c -lfl
I get errors:
[...] undefined reference to '_yywrap'
[...] undefined reference to '_WinMain#16'
Do I understand correctly that I have to compile the content of libfl.a also with i586-mingw32msvc-gcc to be able to use it in this cross-compilation?
In the source code there is function yywrap(), but not _yywrap(). Why I get error for function with underscore _?
Whats up with the _WinMain#16? (no usage in source code)
My goal would be to understand what is happening here.
If I get it to work, then its bonus points :)
Any help is appreciated
Yes, certainly. And here's why:
C++ encodes additional semantic information about functions such as namespace/class affinity, parameter types etc. in the function name (that is called name mangling). Thus C++ library names are somewhat different from what you see in the source code. And each compiler does it in it's own way, that's why generally you're unable to link against C++ functions (C function names don't get mangled still) of a library built with a different compiler.
Judging to mangling style, the undefined symbols are brought in by the Microsoft C++ compiler. I don't know exactly about why it needs WinMain, but after you recompile the libs with it, all these errors likely will be gone. And yes: maybe the WinMain() thing rises from msvc using it instead of main(), which presence is obligatory for a well-formed program? ;)
I have a static library file called libunp.a, I do know I could use gcc -lunp xx to link to the library.
I could use #pragma comment(lib,"xxx.lib") to tell the Microsoft C/C++ compiler to include the library; how could I do it under Linux/GCC?
There doesn't seem to be any mention of any equivalent pragmas in the GCC manual's page on pragmas.
One reason I saw for GCC not supporting linking in source code was that sometimes, correct linking depends on link order; and this would require you to make sure that the linking order happens correctly no matter the order of compilation. If you're going to go to that much work, you may as well just pass the linker arguments on the command line (or otherwise), I suppose.
Libraries should be specified during the linking step. Such information simply
doesn't belong inside a translation unit. A translation unit can be preprocessed,
compiled and assembled even without a linking stage.
Simply because #pragma comment(lib,"xxx.lib") is in the source file does not mean the compiler consumes it. In fact, it goes in as a comment and is subsequently used by the linker. Not much different than *nix.
Use this GCC flag to generate an error for unknown pragmas. It will quickly tell you if the compiler understands it.
-Werror=unknown-pragmas