Tag: ld

什么是链接符号__TMC_END__和__TMC_LIST__？

我已经问了这个问题 ，偶然发现了似乎是由链接器生成的__TMC_END__符号。 我不知道它的目的是什么，唯一有用的参考是这个bug并没有解释为什么它存在。 但是，它会引用类似的符号__TMC_LIST__ 。 有谁知道这些用途是什么？

当main.c不使用pthreads时，为什么必须在main.c编译中显式链接到pthreads？

在Linux中，我有一个使用pthreads的共享库和没有的。 libpthread.so显示在我的共享库的ldd中，这是正确的。 $ ldd libmapreduce.so.1.0 linux-gate.so.1 => (0x0067d000) libpthread.so.0 => /lib/libpthread.so.0 (0x0058c000) […] 但是当我编译并链接不使用pthreads的main.c到我的共享库时，我看到： $ icc -Wall -o main main.c -lmapreduce /opt/intel/Compiler/11.1/046/lib/ia32/libiomp5.so: undefined reference to `pthread_atfork’ 将-lpthread添加到我的编译命令，即 $ icc -Wall -o main main.c -lmapreduce -lpthread 解析未定义的引用。 当我的main.c不使用它并且我的共享库已经链接了libpthread时，为什么我需要显式链接到libpthread？

如何将来自不同.a文件的数据收集到一个数组中？ 如何使用ld脚本保留.a文件中的节？

我需要从不同的.a文件中收集一些数据到一个数组。 我通过收集数据到一个部分来做到这一点 第一个.c文件 TArElement __attribute__((section(“.my.special.section”))) uwiveuve = { … 第二个.c文件 TArElement __attribute__((section(“.my.special.section”))) egwegwxb = { … 等等 在ld脚本中 __my_mega_array_begin = ABSOLUTE(.); KEEP(*(.my.special.section)) __my_mega_array_end = ABSOLUTE(.); 在主.c文件中 extern TArElement *__my_mega_array_begin extern TArElement *__my_mega_array_end const t_size array_size = __my_mega_array_end – __my_mega_array_begin; 所以任何人都可以将他的代码链接到我的代码，我的代码将知道他的代码中的数据。 好吧，它可以工作，但实际上并不…问题是KEEP指令完全与.o文件一起工作，但不是.a。 如果在.a文件中的特定.o文件中没有使用任何部分，那么即使使用KEEP指令，整个.o文件也将从链接中丢弃。 对ld使用–whole-arhive选项会有所帮助，但出于某些原因我不允许使用此选项。 我应该只使用ld脚本文件… 解决问题的另一种方法是通过创建可重定位文件来使用部分链接。 因此.a文件中的所有.o文件都将链接到一个.o文件。 但我也不允许使用部分链接。 所以我应该只使用ld脚本并使用.a文件。

使用Go 1.5 buildmode = c-archive与从C链接的net / http.Server

即将发布的Go 1.5版本附带了新的构建模式 ，允许导出Go符号从C代码链接和调用。 我一直在玩它并得到基本的“Hello world”示例，但是现在我正在尝试链接一个启动net/http.Server的Go库并且它失败了。 代码看起来像这样（ 它也可以在这里获得 ）： gohttplib.go： package main import “C” import “net/http” //export ListenAndServe func ListenAndServe(caddr *C.char) { addr := C.GoString(caddr) http.ListenAndServe(addr, nil) } func main() {} 实例/ C / main.c中： #include #include “../../gohttplib.h” int main() { ListenAndServe(“:8000”); return 0; } 生成静态链接的对象和标头工作正常： $ go build -buildmode=c-archive 但是编译它是失败的： $ gcc -o gohttp-c examples/c/main.c […]

gcc的“-Wl，option”和“-Xlinker option”语法之间的任何区别

我一直在查看一些配置文件，我已经看到两者都被使用（虽然在不同的架构上）。 如果你在linux盒子上使用gcc，那么将选项传递给链接器的两种语法之间有什么区别吗？ 阅读gcc手册，就我所知，它们几乎完全相同。

ld：无法对非PE输出文件错误执行PE操作

我是操作系统编程的新手，我正在阅读一本书，它给出了一个简单的内核示例如下： main() { char *video_memory = 0xb8000; *video_memory = ‘X’; } 要编译这个名为kernel.c的文件，我在Windows 7下使用MinGW，如下所示： gcc -ffreestanding -c kernel.c -o kernel.o 这将创建目标文件kernel.o。 但是，以下命令不起作用。 ld -o kernel.bin -Ttext 0x1000 kernel.o –oformat binary 我收到以下错误： ld: cannot perform PE operations on non PE output file ‘kernel.bin’ 我无法解决问题。 请帮我。 谢谢 在罗斯的帮助下，我成功地跳到内核偏移。 但是，我无法从Kernel_entry.asm调用C函数。 此外，当我从我的kernel.bin中删除C函数并更改下面的代码时，屏幕上会显示三个奇怪的字符。 Kernel_entry.asm如下： [bits 32] ;[extern _start] mov ebx, MSG_KERNEL_ENTRY […]

未定义的引用`log’

我正在尝试编译Donald Eastlake的RFC 3797随机选择算法的实现（代码： http ： //kambing.ui.ac.id/minix/other/rfc3797/ ）。 但是，我收到链接器错误： rfc3797.c:(.text+0xe7f): undefined reference to `log’ 我试图用提供的Makefile来实现它，它明确地链接到数学图书馆，但我仍然得到错误： cc -lm -o randomselection rfc3797.c MD5.c 我该如何编译这个程序？

LD_PRELOAD和链接

我有这个小测试atfork_demo.c ： #include #include void hello_from_fork_prepare() { printf(“Hello from atfork prepare.\n”); fflush(stdout); } void register_hello_from_fork_prepare() { pthread_atfork(&hello_from_fork_prepare, 0, 0); } 现在，我以两种不同的方式编译它： gcc -shared -fPIC atfork_demo.c -o atfork_demo1.so gcc -shared -fPIC atfork_demo.c -o atfork_demo2.so -lpthread 我的演示主要是atfork_demo_main.c是这样的： #include #include #include int main(int argc, const char** argv) { if(argc <= 1) { printf("usage: … lib.so\n"); return 1; } […]

手动指定特定链接符号的重新映射

如果不修改这两个源文件，有没有办法通过编译它们来获取生成的目标文件，并说服链接器将main_v1.c中的foo链接到bar.c中的bar ？ main_v1.c void foo(void); int main(void) { foo(); } bar.c #include void bar(void) { puts(“bar()!”); } 修改目标文件本身是公平的游戏，但假设我们甚至可能没有可用的源代码。 该平台是Linux。 通过坚持对main_v1.c的适度更改，并链接到一个额外的“映射”对象文件，这里几乎可以用标准C获得所需的结果。 main_v2.c extern void (*const foo)(void); int main(void) { foo(); } bar.c没有变化。 map.c void bar(void); void (*const foo)(void) = bar; 如果使用lto编译目标文件，则甚至可以省略函数指针取消引用（使用最近的gcc）。 这是一个非常好的结果但是如果修改main()以直接调用bar() ，那么bar()本身在链接后内联，因此还有改进的余地。

链接器脚本.relocate部分的第一个符号_srelocate是不正确的（GCC Bug？）

问题 我的问题是，当我使用以下脚本打算将代码放入RAM时，重定位部分会填充虚假数据。 我的问题是： 为什么_srelocate符号比_srelocate符号大4个字节？ 它们不应该是一样的吗？ 另外，如果1.的答案为NO，我不应该从_etext + 4复制到_srelocate吗？ 背景和相关代码 我正在使用Atmel ATSAM3N4X系列处理器（ARM Cortex M3），并希望对我的链接器脚本和.relocate部分初始化有所帮助。 原因是_etext符号比_srelocate符号小4个字节。 以下链接描述文件是Atmel Studio 6生成的默认脚本（如果您希望ram / rom符号位置看到问题的Apendix ）。 /* —————————————————————————- * SAM Software Package License * —————————————————————————- * Copyright (c) 2012, Atmel Corporation * * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, […]