In dynamic linking loading,
the functions like dlopen() use the flags like RTLD_LOCAL and RTLD_NOW.
(https://linux.die.net/man/3/dlopen)
What does RTLD stand for?
What does RTLD stand for?
The RunTime LoaDer
Related
I see that there are syslog(2) and syslog(3).
https://man7.org/linux/man-pages/man2/syslog.2.html
https://man7.org/linux/man-pages/man3/syslog.3.html
Since they have the same function time, I don't see how the linker can distinguish them at link time. Could anybody help me understand how the linker correctly resolve the object code under the hood? Thanks.
It doesn't.. syslog(2) has to be called using klogctl() wrapper or using syscall() at your own peril.. syslog(3) is the only definition present in the C library.
Suppose we call
gcc -Dmyflag -lmylib mycode.c
where mylib contains all of mycode but is compiled without -Dmyflag. So all functions and other entities implemented in mycode are available in two versions to the loader. Empirically, I find that the version from mycode is taken. Can I rely on that? Will mycode always overwrite mylib?
Empirically, I find that the version from mycode is taken.
Read this explanation of how linker works with archive libraries, and possibly this one.
Can I rely on that?
You should rely on understanding how this works.
If you understood material in referenced links, you'll observe that adding main to libmylib.a will invert the answer (and if mycode.c also contains main, you'll get duplicate symbol definition error).
If you are using a dynamic library libmylib.so, the rules are different, and the library will always lose to the main binary, although there are many complications, such as LD_PRELOAD, linking the library with -Bsymbolic, and others.
In short, you should prefer to not do this at all.
I'm developing a program which generates certain parts of it as c/c++ libraries.
E.g. it creates directories - lib1, lib2, .. , libN.
For each library it generates c/c++ code + Makefile, then it uses gcc/g++ + ld and finally it calls the code from libraries.
Now the problem is that if lib1 has a function fun and libN as well, when calling fun from libN, lib1 is used.
I've tried different versions of gcc/g++ up to v4.7.
Now the problem is that if lib1 has a function fun and libN as well, when calling fun from libN, lib1 is used.
Presumably you are talking about shared libraries, and not archive libraries (where you'd get a multiply-defined symbol error).
Yes, that is how it is supposed to work, and has always worked on UNIX. Caching has nothing to do with it.
If you are on ELF platform, you might be able to make it work more Windows-like by using -Wl,-Bsymbolic, but you'll be fighting the default system behavior, and should expect rough ride, and lots of unexpected gotcha's. If the fun doesn't need to be exposed from libX, hidden symbol visibility is your friend.
Since you are generating the code for lib1, ... libN, it might be easier to simply avoid name collision by using e.g. libX_fun instead of fun. This would also be much more portable, as it will just work everywhere.
Update:
function name has really to be fun according to the interface specifications.
According to who's interface specifications?
You obviously control both the main program, and the libraries. So you can, and likely should change the interface specification to avoid this problem.
I don't know if this is the right place for things like this, but I am curious about a few aspects of the GCC front-end/back-end architecture:
I know I can compile .o files from C code and link them to C++ code, and I think I can do it the other way round, too. Does this work because the two languages are similar, or because the GCC back-end is really language-independent? Would this work with ADA code too? (I don't even know if that makes sense, since I don't know ADA or if it even has "functions", but the question is understood. If it makes no sense, think "Pascal" or even "my own custom language front-end")
Where would garbage-collection be implemented? For example, a Java front-end. The way I understand, if compiling to a JVM back-end, the "platform" will take care of the GC, and so the front-end needs not do anything about it, but if compiling to native code, would the front-end send garbage-collecting GENERIC code to the back-end, or does it turn on some flag telling the back-end to produce garbage-collecting code? The first makes more sense to me, but that would mean the front-end produces different output based on the target, which seems to miss the point of the GCC's front-end/back-end architecture.
Where would language-specific libraries go? For instance, the standard Java classes or standard C headers. If they are linked in at the end, then could a C program theoretically call functions from the Java library or something like that, since it is just another linked library?
Yes, the backend is at least reasonably language independent. Yes, it works with Ada.
GCJ generates native code which uses a runtime library. The garbage collector is part of the runtime library.
GCJ implements the CNI, which allows you to write code in C++ that can be used as native methods by Java code -- but being able to do this is a consequence of them having designed it in, not just an accidental byproduct of using the same back-end.
It is possible because calling convention is compatible, but name mangling is different (no mangling in C). To call C function from C++ you should declare it with extern "C". And to call C++ function from C you should declare it with mangled name (and may be with additional or different type args). The calling Fortran code is possible in some cases too, but argument passing convention is different (pass by ref in Fortran).
There were actually a converters from C++ to C (cfront) and from fortran to c (f2c) and some solutions from them are still used.
garbage-collection is implemented in run-time library, e.g. boehm. Backend should generate objects compatible with selected GC library.
Compiler driver (g++, gfortran, ..) will add language-specific libraries to linking step.
Is there any way to tell the compiler (gcc/mingw32) when building an object file (lib*.o) to only expose certain functions from the .c file?
The reason I want to do this is that I am statically linking to a 100,000+ line library (SQLite), but am only using a select few of the functions it offers. I am hoping that if I can tell the compiler to only expose those functions, it will optimize out all the code of the functions that are never needed for those few I selected, thus dratically decreasing the size of the library.
I found several possible solutions:
This is what I asked about. It is the gcc equivalent of Windows' dllexpoort:
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Code-Gen-Options.html (-fvisibility)
http://gcc.gnu.org/wiki/Visibility
I also discovered link-time code-generation. This allows the linker to see what parts of the code are actually used and get rid of the rest. Using this together with strip and -fwhole-program has given me drastically better results.
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html (see -flto and -fwhole-program)
Note: This flag only makes sense if you are not compiling the whole program in one call to gcc, which is what I was doing (making a sqlite.o file and then statically linking it in).
The third option which I found but have not yet looked into is mentioned here:
How to remove unused C/C++ symbols with GCC and ld?
That's probably the linkers job, not the compilers. When linking that as a program (.exe), the linker will take care of only importing the relevant symbols, and when linking a DLL, the __dllexport mechanism is probably what you are looking for, or some flags of ld can help you (man ld).