ld

问题 I am compiling a c "hello world" program that juste include one simple function and a main function. I am using GCC under Linux. When I run readelf command on the binary, I can see symbol table and I can see function names in clear. Is there a way to tell GCC (or the linker) to not generate this symbol table? Is it possible to tell GCC to store only functions addresses, without storing function names in clear? 回答1: The utility strip discards symbols from object files. Consider : #include

问题 I'd like to write a linker script looking something like this: SECTIONS { . = 0x0; .startup . : { startup.o(.text) } .text : { *(.text) } .data : { *(.data) } .bss : { *(.bss COMMON) } . = 0x4000; other.text : { other.o(.text) } other.data : { other.o(.data) } other.bss : { other.o(.bss) } } My intention here is to have, in this order: a section with the .text from startup.o .text , .data and .bss containing those sections from all other input files besides other.o the .text , .data and .bss

问题 I’m building a dynamic framework for iOS. It needs reference some symbols from code or other libraries, but I not want link them into the framework. This can be achieved when build an static library, just setup search path and make sure them not included in target’s build phases. But when build a dynamic framework or dylib, this result undefined symbol error. I tried all kinds of link options, eg -l -weak_library -weak_framework -I -rpath -rpath-link . But none works. The link command looks

问题 I try to to port a linux software to OS X (Yosemite) which uses CMake to be built. The only modification that I necessarily made, was to direct to the Homebrew installed GNU GCC and G++ when executing cmake . If I use the already existing CMakeLists.txt, the build process stops with the following error: ld: unknown option: --start-group collect2: error: ld returned 1 exit status make[2]: *** [lib/somelib.dylib] Error 1 make[1]: *** [lib/somelib.dir/all] Error 2 make: *** [all] Error 2

问题 According to the ld manual on the special symbol ., i.e.the Location Counter. Note: . actually refers to the byte offset from the start of the current containing object. Normally this is the SECTIONS statement, whose start address is 0, hence . can be used as an absolute address. If . is used inside a section description however, it refers to the byte offset from the start of that section, not an absolute address. Thus in a script like this: SECTIONS { . = 0x100 .text: { *(.text) . = 0x200 }

问题 I have this library which involves some static initialization code which needs to run before main() . It all works well if you just compile all of the translation units together, but it doesn't work if I provide a static library ( .a file) and have users link their application against it - the linker simply ignores the symbols which do my static initialization. Alternatively, I can make the linker pick up everything in the static library, if I specify the -Wl,--whole-archive option to GCC, i

问题 I've been trying to make some applications which all rely on the same library, and dynamic libraries were my first thought: So I began writing the "Library": /* ThinFS.h */ class FileSystem { public: static void create_container(string file_name); //Creates a new container }; /* ThinFS.cpp */ #include "ThinFS.h" void FileSystem::create_container(string file_name) { cout<<"Seems like I am going to create a new file called "<<file_name.c_str()<<endl; } I then compile the "Library" g++ -shared

问题 The packages I'm toying with here are rather unknown, but nevertheless the problem is rather generic. Basically, I'm trying to compile Python module (called rql) with C++ extension. The extension uses external framework called gecode, which contains several libraries. I compiled gecode and installed locally. Now, let the output speak for itself: red@devel:~/build/rql-0.23.3$ echo $LD_LIBRARY_PATH /home/red/usr/lib red@devel:~/build/rql-0.23.3$ ls $LD_LIBRARY_PATH | grep libgecodeint

问题 I maintain an open-source framework that uses CircleCI for continuous integration. I've recently hit a wall where the project suddenly refused to build in rather strange circumstances. Build 27 was the last one that succeeded. After that, I made some minor changes to dependencies and noticed that the build fails. I've tried to fix it without success, so I reverted back to last working configuration and it still failed. The reason for failure are two dependencies, both being bindings to native

问题 I need to use an alternate glibc version, newer than the one installed on my system ( 2.18 vs 2.15 ). Several related issues are covered here and here. The specific question I'm asking here is the following: I set up the library path of the new dynamic linker ( ld-2.18.so ) so that the new libc ( libc-2.18.so ) is found ahead of the old libc ( libc-2.15.so ). However, when I try to run a program with the new ld , the old version of libc is picked up, generating a SEGV . Why is that happening?