linker

问题 Symbols can be linked at certain addresses with defsym as illustrated here. My question is whether the same can be done with sections? That is, given some .o object file, is it possible to specify the base address that sections will be relocated to? Alternatively, is it possible to rebase a section after the final link? That is, to change the address of a section in a binary and have all information affected by relocation (such as relative branches out of the section, etc.) to be relocated

问题 I am using Ubuntu 10.04 and trying to compile some code that uses gfortran. At some point Makefiles does: -L. -lgfortran and I get the error /usr/bin/ld: cannot find -lgfortran although it is installed: ldconfig -p | grep fortran libgfortran.so.3 (libc6,x86-64) => /usr/lib/libgfortran.so.3 How can I fix it? P.S: The Makefile: ## FLAGS CC:= gcc C++:= g++ CFLAGS:= -c -O -Dintel -g FC:= gfortran FFLAGS:= -c -O -cpp -g LD:= g++ LDFLAGS:= -O WETTER_CGAL_FLAGS:= -g #WETTER-Data WETTER_cgal: weather

问题 Is it possible to use a library compiled by visual studio in an application compiled by g++ (mingw) on Windows? 回答1: If the library is written in C++ and exposes a C++ interface: no (because the name-mangling differs between g++ and VC++). If the library is a static library written in C (or with an extern "C" interface): yes, but certain caveats apply. If the library is a DLL with a C interface: yes, but you'll have to create your own import library. 回答2: Also see the discussion for question

问题 Until some time ago, I thought a .a static library was just a collection of .o object files, just archiving them and not making them handled differently. But linking with a .o object and linking with a .a static library containing this .o object are apparently not the same . And I don't understand why... Let's consider the following source code files: // main.cpp #include <iostream> int main(int argc, char* argv[]) { std::cout << "main" << std::endl; } // object.hpp #include <iostream> struct

问题 I have a program that depends on a shared library it expects to find deep inside a directory structure. I'd like to move that shared library out and into a better place. On OS X, this can be done with install_name_tool. I'm unable to find an equivalent for Linux. For reference, readelf -d myprogram spits out the following paraphrased output: Dynamic section at offset 0x1e9ed4 contains 30 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [this/is/terrible/library.so] 0x00000001

问题 This is strange because I was able to get the error below to go away by removing the reference to libm. gcc -o example example.o -Wl -L/home/kensey/cdev/lib -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -L/usr/lib/x86_64-linux-gnu -lm -lrt -ldl -lcdev -L/home/kensey/www.tools/gplot-lib -lgplot -L/home/kensey/www.tools/gd1_3ret -lgd -lxml2 -lcurl /usr/bin/ld: /home/kensey/www.tools/gplot-lib/libgplot.a(set.o): undefined reference to symbol 'floor@@GLIBC_2.2.5' /usr/bin/ld: note:

问题 If a friend wants to run my Haskell binaries, does he have to first install Haskell, or can he immediately run the binary by itself? Is the answer the same on Mac, Windows, and Linux? 回答1: GHC does produce stand-alone binaries that do not require GHC itself to be installed, however they do link against some dynamic libraries, most notably libgmp . The remaining libraries are commonly found out of the box on most Linux systems. I believe the situation is similar on Windows. You can check which

问题 During compilation and linking, what is use of .exp? What is the difference between .lib and .dll? I know that .lib will be used, while linking and .dll will be used when running the program. But what exactly is the difference between .lib and .dll? Does .lib file not contain the code for the functions coming from .dll files? What is the need for using two separate files? Please clarify. 回答1: In the case of an import library for a DLL, the .lib file does not contain any actual code at all. It

问题 I have a problem linking some shared library with g++. It gives me a warning like: hidden symbol XXX in YYY is referenced by DSO /usr/lib/... I've read some related questions about particular problems, but I want to understand it in a whole - what does this warning mean and what is a cause: What is DSO? What is a hidden symbol? How can it be referenced, if it's hidden? 回答1: What is a DSO? A DSO is a Dynamic Shared Object , or less formally a shared library. What is a hidden symbol? A hidden

问题 EDIT : If you fall on this post, you may want to jump directly to the answer I sent a post about my confusion earlier this morning machine type (C++ librairies) : i386 vs x86_64 But I guess I did a mistake by being not precise. So I decided to give an example of situations I face and that I can not understand. STEP 1 I build a library on machine A, a 2 years old mac with OS x 10.7.5 (that I guess is 64 bits; my guess being based on the commands you will see below in Additional Info) using the