I wish to know how the Shared library works I am asking in terms of Symbol table reference.
Is it like when we include a shared library it exports the Symbol table to process then based on some pointers we execute the respective function.
What is the meaning of Shared library Strip ?
Edit :- I wish to know that how shared library works when it get loaded into the memory.\
When a function lets say Fun() get called from the application which has def in library. then how this linking happen . I hope now its clear.
Programs make calls to a shared library through a Procedure Linkage Table, which is filled in by the dynamic linker/loader ld.so based on the information in the dynamic symbol table and relocation entries. On Linux this data is stored in programs and libraries in the ELF format, which you can inspect using programs like objdump and readelf.
This Linux Journal article has a basic overview. For more detailed information check out Ulrich Drepper's excellent paper How To Write Shared Libraries, and the Solaris Linker and Libraries Guide.
Related
There's a well-known technique for interposing dynamically linked binaries: creating a shared library and and using LD_PRELOAD variable. But it doesn't work for statically-linked binaries.
One way is to write a static library that interpose the functions and link it with the application at compile time. But this isn't practical because re-compiling isn't always possible (think of third-party binaries, libraries, etc).
So I am wondering if there's a way to interpose statically linked binaries in the same LD_PRELOAD works for dynamically linked binaries i.e., with no code changes or re-compilation of existing binaries.
I am only interested in ELF on Linux. So it's not an issue if a potential solution is not "portable".
One way is to write a static library that interpose the functions and link it with the application at compile time.
One difficulty with such an interposer is that it can't easily call the original function (since it has the same name).
The linker --wrap=<symbol> option can help here.
But this isn't practical because re-compiling
Re-compiling is not necessary here, only re-linking.
isn't always possible (think of third-party binaries, libraries, etc).
Third-party libraries work fine (relinking), but binaries are trickier.
It is still possible to do using displaced execution technique, but the implementation is quite tricky to get right.
I'll assume you want to interpose symbols in main executable which came from a static library which is equivalent to interposing a symbol defined in executable. The question thus reduces to whether it's possible to intercept a function defined in executable.
This is not possible (EDIT: at least not without a lot of work - see comments to this answer) for two reasons:
by default symbols defined in executable are not exported so not accessible to dynamic linker (you can alter this via -export-dynamic or export lists but this has unpleasant performance or maintenance side effects)
even if you export necessary symbols, ELF requires executable's dynamic symtab to be always searched first during symbol resolution (see section 1.5.4 "Lookup Scope" in dsohowto); symtab of LD_PRELOAD-ed library will always follow that of executable and thus won't have a chance to intercept the symbols
What you are looking for is called binary instrumentation (e.g., using Dyninst or ptrace). The idea is you write a mutator program that attaches to (or statically rewrites) your original program (called mutatee) and inserts code of your choice at specific points in the mutatee. The main challenge usually revolves around finding those insertion points using the API provided by the instrumentation engine. In your case, since you are mainly looking for static symbols, this can be quite challenging and would likely require heuristics if the mutatee is stripped of non-dynamic symbols.
I have a object file which has a main() function inside and just needs to be linked with crt... objects to be an executable . Unfortunately I can only compile and I can not link it to be an executable .
so I decided to create a c program ( on a pc with working GCC and linker ) to attach object(s) at the end of itself and execute the codes attached at run time (simulating a linked object ).
I saw DL API but I do'nt know how to use it for the problem I said .
May sb help me to know , how I can executing a code attached at the end of an executable .
Avoid doing that; it would be a mess .... And it probably won't reliably work, at least if the program is dynamically linked to the libc6.so (e.g. because of ASLR)
Just use shared objects and dynamically linked libraries (See dynamic linker wikipage). You need to learn about dlopen(3) etc.
If you really insist, take many weeks to learn a lot more: read Levine's book on Linker and Loaders, read Advanced Linux Programming, read many man pages (including execve(2), mmap(2), elf(5), ld.so(8), ...) study the kernel code for execve and mmap, the GNU libc and MUSL libc source codes (for details about implementations of the dynamic linker), the x86-64 ABI or the ABI for your target processor (is it an ARM?), learn more about the GNU binutils etc, etc, etc.
In short, your life is too short doing such messy things, unless you are already an expert, e.g. able to implement your own dynamic linker.
addenda
Apparently your real issue seems to use tinycc on the ARM (under Android I am guessing). I would then ask on their mailing list (perhaps contribute with some patch), or simply use binutils and make your own GNU ld linker script to make it work. Then the question becomes entirely different and completely unrelated to your original question. There might be some previous attempts to solve that, according to Google searches.
For example, the description of /lib/ is that it contents shared library files for the system.
What exactly is a library? Are we talking about library files similarly to importing a library in C? What is contained in a library file and what are they used for?
What relation does it have to a .dll
A library is just a block of code, and sometimes data, that can be used by other programs. Objects in a static library get physically included in a program's code at linking time, and each program using them will have its own copy. Objects in a shared library will be accessed by a program at run time. A .dll is just Microsoft's word for a shared library, the equivalent on Linux would usually be .so.
A library is a collection of routines that can be called from different programs or libraries. Dynamic (shared) libraries can be loaded at runtime, so the library can be swapped without having to recompile the programs using it. /lib/ contains the libraries available on your operating system, but they don't have to be C libraries.
.dll is the Windows equivalent of shared libraries (.so).
I'm interested how does linux act in situation that pictured.
You can see library "A" is staticaly linked with application. But this application depends on dynamic library B, and it in turn depends on library A.
So, what library A will use dynamic library B? Staticaly linked library A in my application or it will again load additional library A.
It's important in case if these libraries have different versions.
Also you can suggest me some articles about me, cause for me linker is like black box.
Dynamically linked library B libB.so -which should be dynamically linked, when libB.so is built, to libA.so will not see the statically linked libA.a (even worse, it might have duplicate global variables of that library, so that could give you a nightmare).
Actually, libA.a does not exist in the ELF executable of your main program. Only some but not all object files a*.o from libA.a are statically linked inside your executable (those actually needed).
See Levine Linkers and Loaders book, wikipage on dynamic linking and on ELF, and Drepper's paper How To Write Shared Libraries. See also ld.so(8), ldconfig(8), ldd(1), dlopen(3), mmap(2), proc(5) man pages. Use strace, and try once cat /proc/self/maps ...
In short avoid linking both statically and dynamically the same library (even of similar or different versions).
Rule of thumb: always link dynamically, except when you know what you are doing and why...
My question is not the same as this question.
I'm working on a project with a standalone binary that has no dynamic/external linkage, and runs in a *nix environment.
I'm attempting to move to a newer toolset to build with, but some of the static libraries that are available with the older toolset aren't available now -- for example, the crt libraries that provided _start aren't provided in this toolset.
I've been digging through the files provided with the vendor's toolset and found some shared objects with the symbols I needed from the crt libraries (eg, _start, _fini, etc) but I'm unsure whether there's a straightforward way to statically link a shared object into a binary, and further have that binary be executable.
Short version: Can a non-shared-object binary be statically linked with a shared object without the result becoming another shared object?
There's a fundamental difference between a shared library and a static library. First off, do search this site for previous discussions, and check out this question too (and the answers therein).
Basically, a static library is just a collection of objects, and the linker resolves the symbol names into fixed addresses -- this is required for static linking. On the other hand, a shared library is much more like an independent executable, which is loaded into memory by the loader and has entry point addresses to which the program jumps. However, relocation tables that static libraries have are generally not preserved when a shared library is being linked, so it's in general not possible to extract linkable object code from inside a linked shared library.
Yeah, I know this is an 6 year-old question. I was told that it was possible to statically link against a shared-object library, but I've also discovered that it is not.
To actually demonstrate that statically linking a shared-object library is not possible with ld (gcc's linker), use the following gcc command:
gcc -o executablename objectname.o -Wl,-Bstatic -l:libnamespec.so
(Of course you'll have to compile objectname.o from sourcename.c, and you should probably make up your own shared-object library as well. If you do, use -Wl,--library-path,. so that ld can find your library in the local directory.)
The actual error you receive is:
/usr/bin/ld: attempted static link of dynamic object `libnamespec.so'
collect2: error: ld returned 1 exit status
Clearly, attempting to pull the object out of the shared-object library is something about which ld will balk.
There were some suggestions made here, but my interest in this question was merely academic.
Hope that helps.