dynamic-linking

问题 I have been reading about the relocation and symbol resolution process and I have a few questions on the same. So the whole process(of loading the exec) starts with exec(BA_OS) command. During exec(BA_OS) , the system retrieves a path name from the PT_INTERP segment and creates the initial process image from the interpreter file’s segments. That is, instead of using the original executable file’s segment images, the system composes a memory image for the interpreter. It then is the interpreter

问题 Intuitively: MinGW-w64 is a Windows port of the GNU compiler tools (GCC, etc.). Pre-compiled binaries for Windows are .dll (dynamic linking) / .lib (static linking). However, MinGW-w64 uses the GNU compiler tools, it would follow that .so / .a binaries are required. What I've Found: According to Red Hat Enterprise Linux documentation, seems that MinGW/MinGW-w64/Cygwin linkers look for .dlls and .as According to this tutorial, you should dynamically link to .so and statically link to .a . One

问题 Why we need the presence of the shared library during the compile time of my executable? My reasoning is that since shared library is not included into my executable and is loaded during the runtime, it is not supposed to be needed during compile time. Or Am I missing something? #include<stdio.h> int addNumbers(int, int); //prototype should be enough, no? int main(int argc, char* argv[]){ int sum = addNumbers(1,2); printf("sum is %d\n", sum); return 0; } I had the libfoo.so in my current dir

问题 I'm really trying to understand the steps from high level code -> executable.. but am having some difficulties. I've written an empty int main() {} C file and am trying to decipher the disassembly via objdump -d . Here's what's going on: in _start , set up alignment, push arguments on stack, call __libc_start_main in __libc_start_main , the first line to execute is jmp *0x8049658 However, upon using objdump -R to check out the relocation records, the value in 0x8049658 is __libc_start_main

问题 I'm really trying to understand the steps from high level code -> executable.. but am having some difficulties. I've written an empty int main() {} C file and am trying to decipher the disassembly via objdump -d . Here's what's going on: in _start , set up alignment, push arguments on stack, call __libc_start_main in __libc_start_main , the first line to execute is jmp *0x8049658 However, upon using objdump -R to check out the relocation records, the value in 0x8049658 is __libc_start_main

问题 I've already read gdb says "cannot open shared object file" and gdb can not open shared object file and followed the instructions. I have a binary which is linked to a shared library file ( /zzz/yyy/xxx.so ). After I set LD_LIBRARY_PATH to /zzz/yyy/ and run the binary without GDB, it executes very well. However, when I was trying to use GDB to debug this binary, GDB says: error while loading shared libraries: xxx.so: cannot open shared object file: No such file or directory I already have

问题 I have the following Problem: I'm trying to create a portable version of my program, so I set rpath to "." so all libraries are linked using the relative file path. And this does work for all libraries except one. For some reason, the program only works if one specific library is present at the same position it was linked when it was compiled. Which is one I wrote myself, which also has its rpath set to ".". So basicly, the program will refuse to start even though the library is at the exact

问题 I have written a custom library which implements malloc/calloc/realloc/free using the standard C prototypes, and I figured out how to compile it to an so. I want to test the library by linking a standard application against it? What would be a good way to do this? Once I have a working library I assume I can just load it with LD_PRELOAD, but how do I get my functions to co-exist with but take precedence over the system library ones? My functions need to make a call to malloc in order to get

问题 I'd like to use libdl to dynamically load C++ in general. The problem is identifying symbols at runtime that have been name mangled. As described here, one solution is to remove name mangling by using extern "C". http://www.tldp.org/HOWTO/C++-dlopen/theproblem.html This solution has the drawback of limiting dynamically loaded resources to C style interfaces. Dynamically loaded functions cannot, for instance, be overloaded functions. What is a good way to overcome this limitation? One possible

问题 I have a third party OS X dylib that I'm using in my app and don't have easy access to its creator. I'd like to determine if it was linked with -flat_namespace. Is that possible? If so, how? 回答1: Run otool -hV on the library. If you don't see TWOLEVEL , then it was linked with -flat-namespace . For example: twolevel.dylib: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 8 672 NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS versus