ld

问题 I'm trying to force a build internal pre-processor used for built-sources to not rely on shared libraries installed in my host machine without having to uninstall them. Although there is a LD_PRELOAD environment variable which forces the loader (ld-linux) to fetch the specified shared libraries before anything else, I'd like to do quite the opposite, forcing the loader not to fetch the specified libraries during the setup process (kind of LD_NEVERLOAD variable). Is there some way to do so

问题 I am having some troubles setting up cross compiling with CMAKE. The toolchain I am using is created in yocto which works perfectly outside of cmake. I have followed a tutorial to setup the following toolchain file: SET(CMAKE_SYSTEM_NAME Linux) SET(CMAKE_SYSTEM_VERSION 1) SET(CMAKE_SYSTEM_PROCESSOR arm) # specify the cross compiler SET(tools /opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr) SET(CMAKE_C_COMPILER ${tools}/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc) SET(CMAKE_CXX

问题 I have performance critical code written for multiple CPUs. I detect CPU at run-time and based on that I use appropriate function for the detected CPU. So, now I have to use function pointers and call functions using these function pointers: void do_something_neon(void); void do_something_armv6(void); void (*do_something)(void); if(cpu == NEON) { do_something = do_something_neon; }else{ do_something = do_something_armv6; } //Use function pointer: do_something(); ... Not that it matters, but I

问题 I need to create a wrapper library for C code that wraps my C++ library. Is there a way to create that wrapper library in such a way, that the user needs to link only this wrapper library and doesn't have to include all the (C++) libraries on the linker command line as well? The structure of my test project looks like this: . ├── lib │ ├── cpp │ │ ├── print.cc │ │ └── print.h │ ├── lib.cc │ ├── lib.h └── main.c The main.c is an example C application that uses my library. The lib.h and lib.cc

问题 I'm linking to a library on my filesystem using ld . When I run the command ld -verbose -lmylib , I get the following back: attempt to open /usr/x86_64-linux-gnu/lib64/libmylib.so failed attempt to open /usr/x86_64-linux-gnu/lib64/libmylib.a failed attempt to open //usr/local/lib/x86_64-linux-gnu/libmylib.so failed attempt to open //usr/local/lib/x86_64-linux-gnu/libmylib.a failed attempt to open //usr/local/lib64/libmylib.so failed attempt to open //usr/local/lib64/libmylib.a failed attempt

问题 Here's the scenario I'm having: I've created a debootstrap ubuntu maverick (64-bit) environment. I placed it at /env/mav/ on my ubuntu (64-bit) lucid system. I can chroot into /env/mav and can utilize a maverick system perfectly. I can even use the lucid programs fine outside the chrooted environment. That is /env/mav/bin/ls will run. However, I noticed that if I modify LD_LIBRARY_PATH to be /env/mav/lib [1] [2] every single program (both lucid and maverick) I run will crash instantly. (e.g.

问题 I'm trying to link directly using ld to isolate a build problem. When I include /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so , I get a few issues: ac-aaa.o: In function `__static_initialization_and_destruction_0': /usr/include/c++/4.7/iostream:75: undefined reference to `__dso_handle' ac-callback.o: In function `__static_initialization_and_destruction_0': /usr/include/c++/4.7/iostream:75: undefined reference to `__dso_handle' ... Searching for __dso_handle : $ grep __dso_handle /usr/lib/gcc

问题 Hi I am currently generating x86 assembly for a compiler that I am writing and am having some trouble linking the file on my 64-bit VM (the assembly code is 32 bit). I was able to assemble the object file fine with this command: as --32 mult.S -o mult.o but I can't seem to find any options for ld that make it generate a 32-bit ELF file: ld <some-option?> mult.o -o mult Any help would be great. 回答1: ld <some-option?> mult.o -o mult ld -m elf_i386 mult.o -o mult You can get a list of available

问题 Hi I am currently generating x86 assembly for a compiler that I am writing and am having some trouble linking the file on my 64-bit VM (the assembly code is 32 bit). I was able to assemble the object file fine with this command: as --32 mult.S -o mult.o but I can't seem to find any options for ld that make it generate a 32-bit ELF file: ld <some-option?> mult.o -o mult Any help would be great. 回答1: ld <some-option?> mult.o -o mult ld -m elf_i386 mult.o -o mult You can get a list of available

问题 I'm trying to use methods contained in a shared library ( libscplugin.so ). I have satisfied all of the libraries requirements: libc.so with a symlink to libc.so.6 libz.so with a symlink to libz.so.1.2.8 libstdc++.so with a symlink to libstdc++.so.6.0.20 Upon compilation I get the following error message: $ gcc test.c -o test -L/usr/lib/arm-linux-gnueabihf/ -lscplugin /usr/bin/ld: test: hidden symbol `stat' in /usr/lib/arm-linux-gnueabihf/libc_nonshared.a(stat.oS) is referenced by DSO /usr