ld

问题 These ideas may seems strange... I've made other environment on my Gnu/Linux system by creating directory and copy there necessary files to bin, lib, usr, etc and others. Then I do 'chroot' and then do some operations inside. The problem is that all files in environment were taken from older OS (2.4 kernel version). But compiler must be taken modern (with support of modern language standarts). When I'm trying to run compiler inside the environment it goes with errors: g++: /lib/libc.so.6:

问题 When I compile linphone source code, error happened below. Can anybody tell me how to fix it. Thank you. ld: unrecognised emulation mode: armelf_linux_eabi Supported emulations: elf_i386 i386linux elf32_x86_64 elf_x86_64 elf_l1om elf_k1om i386pep i386pe C compiler test failed. 回答1: In case anyone is as dumb as me, I was getting this error because, I assume , the linker it was trying to use didn't have execution permissions; in fact, a lot of things didn't have execution permissions. So I did

问题 While it could be clear in the context of a resulting binary or ELF file what is a section, many places in documentation (independently of the compiler used) refers them as to Input or Output sections. What are the differences between these? 回答1: The linker consumes object files (and possibly shared libraries) and outputs an executable or shared library. The input object files are composed of named sections - .text , .data , .rodata , .bss , etc. So is the output file. It is a principal part

问题 Let's assume that I have the following C code: extern int f_1(); extern int g_1(); extern int f_2(); extern int g_2(); extern int f_3(); extern int g_3(); int main(int argc, char **argv) { // Using f_1, f_2, f_3 and g_1, g_2, g_3 here: ... } And I want to build it by linking with 3 different libraries: l1 , l2 , l3 -- assuming each of them exports its own f and g functions -- so that: f_1 and g_1 will be resolved to f and g respectively from l1 ; f_2 and g_2 will be resolved to f and g

问题 here's my problem. I have this linker script that links a standard arm7nommu-uClinux kernel: OUTPUT_ARCH(arm) ENTRY(stext) SECTIONS { . = 0x0; .vectors : { *(.resetvector) } . = 0x8000; .init : { /* Init code and data */ _stext = .; __init_begin = .; *(.text.init) __proc_info_begin = .; *(.proc.info) __proc_info_end = .; __arch_info_begin = .; *(.arch.info) __arch_info_end = .; __tagtable_begin = .; *(.taglist) __tagtable_end = .; *(.data.init) . = ALIGN(16); __setup_start = .; *(.setup.init)

问题 I want to compile the following program on Linux: .global _start .text _start: mov $1, %rax mov $1, %rdi mov $msg, %rsi mov $13, %rdx syscall mov $60, %rax xor %rdi, %rdi syscall msg: .ascii "Hello World!\n" However, it gives me the following linker error: $ gcc -nostdlib hello.s /usr/bin/ld: /tmp/ccMNQrOF.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2:

问题 I am trying to re-compile an existing C++ application. Unfortunately, I must rely on a proprietary library I only have a pre-compiled static archive of. I use g++ version 7.3.0 and ld version 2.30. Whatever GCC version it was compiled with, it is ancient. The header file defines the method: class foo { int bar(int & i); } As nm lib.a shows, the library archive contains the corresponding exported function: T bar__4fooRi nm app.o shows my recent compiler employing a different kind of name

问题 Suppose you have have a makefile containing two targets as in the following: # targetA X86CPPTARGET += targetA targetA,SRCS = FILEA.cpp FILEB.cpp commonFile.cpp targetA.so,DEPSOL = libUsedByCommon1.cpp targetA,CPPFLAGS += -Ifakeinclude -std=c++11 # tartargetBgetA X86CPPTARGET += targetB targetB,SRCS = FILEC.cpp FILED.cpp commonFile.cpp targetA.so,DEPSOL = libUsedByCommon2.cpp targetB,CPPFLAGS += -std=c++11 targetA and targetB share a file, namely, commonFile.cpp which contains a number of

问题 I'm compiling a very simple hello-world one-liner statically on Debian 7 system on x86_64 machine with gcc version 4.8.2 (Debian 4.8.2-21): gcc test.c -static -o test and I get an executable ELF file that includes the following sections: [17] .tdata PROGBITS 00000000006b4000 000b4000 0000000000000020 0000000000000000 WAT 0 0 8 [18] .tbss NOBITS 00000000006b4020 000b4020 0000000000000030 0000000000000000 WAT 0 0 8 [19] .init_array INIT_ARRAY 00000000006b4020 000b4020 0000000000000010

问题 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