linker

问题 I'm overriding C++ global new/delete operators on Linux project. It all works nicely in my own code, until I found out that the new/delete symbols in system libraries gets also replaced with my code! This is a very bad problem since it goes way beyond 'level of evil' I intended. So question is how do I prevent the linker/compiler from replacing the new/delete syms from other (system) shared libraries? Or more precisely how do I control what shared libraries link syms from my library? I would

问题 I'm overriding C++ global new/delete operators on Linux project. It all works nicely in my own code, until I found out that the new/delete symbols in system libraries gets also replaced with my code! This is a very bad problem since it goes way beyond 'level of evil' I intended. So question is how do I prevent the linker/compiler from replacing the new/delete syms from other (system) shared libraries? Or more precisely how do I control what shared libraries link syms from my library? I would

问题 I have a user program which normally compiles to have an entry point at 0x400460 which I have to relocate to have an entry point starting at within 2GB of the shared libraries loaded in Linux. e.g linux-vdso.so.1 => (0x00007fff109cd000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcd195e6000) /lib64/ld-linux-x86-64.so.2 (0x00007fcd199af000) I am using gcc command line argument -Wl,-Ttext=0x80000000 to specify the start address for the .text segemnt. The issue is that when I am giving

问题 I've got a variable called global_count that I would like to share between the shared library and the main part of the program (and ultimately other libs, but for now I've simplified the testcase). Given the declaration of global_count in globals.cpp: extern "C" { int* global_count; } We compile to create a global.o file: gcc -c global.cpp shared.cpp below will be used to create shared.so : #include <stdio.h> #include "global.h" extern "C" { void init_global_count(int* xp) { printf(

问题 In terms of embedded development using C code, I understand that when a program is compiled and linked, a binary or ELF file is produced which executes on the target. The ELF file will contain (along with alot of other stuff ) the addresses or address offsets of global variables. Now, when the C startup code executes first, it can copy non-const data / variables from flash memory into RAM if this data is to be modified throughout the program. This will then change the memory addresses of the

问题 I have an Ada program that was written for a specific (embedded, multi-processor, 32-bit) architecture. I'm attempting to use this same code in a simulation on 64-bit RHEL as a shared object (since there are multiple versions and I have a requirement to choose a version at runtime). The problem I'm having is that there are several places in the code where the people who wrote it (not me...) have used Unchecked_Conversions to convert System.Addresses to 32-bit integers. Not only that, but

问题 I have an Ada program that was written for a specific (embedded, multi-processor, 32-bit) architecture. I'm attempting to use this same code in a simulation on 64-bit RHEL as a shared object (since there are multiple versions and I have a requirement to choose a version at runtime). The problem I'm having is that there are several places in the code where the people who wrote it (not me...) have used Unchecked_Conversions to convert System.Addresses to 32-bit integers. Not only that, but

问题 I am having problems with the linker when porting a C library from Linux (Ubuntu) to OS X. The C code is auto-generated from Matlab, so ideally I don't want to change the code itself. The problem seems to be in a C file which contains ONLY uninitialised variable declarations, which are then EXTERNed by other C files to implement the Matlab algorithms. The OS X linker is apparently unable to recognise symbols from this file. The same source code works fine on Linux, so I want to understand how

问题 I'm trying to run some MPI programs in xcode 4. I installed openmpi from MacPort by typing sudo port install openmpi and the installation finished normally. Then I added opt/local/include/openmpi to my user header search paths, dragged the "libmpi.dylib" and "libmpi_cxx.dylib" into my project. But then when I tried to run the program, I got the following error message: Undefined symbols for architecture x86_64: "_MPI_Comm_accept", referenced from: MPI::Intracomm::Accept(char const*, MPI::Info

问题 I am having trouble generating a shared object from a static library. While I know there are other alternatives, I am now bothered (as opposed to stuck) by why this isn't working and how to make it work. Below is very simple source code I am using. get_zero.c #include "get_zero.h" int get_zero(void) { return 0; } get_zero.h int get_zero(void); main.c #include <stdio.h> #include <string.h> #include "get_zero.h" int main(void) { return get_zero(); } The goal is create two functionally equal