c - 这是一个 gcc 错误吗？

Question

基本上，我已经发布了一些关于我的问题的问题。但是，我相信这是一个不同的问题。

简单地说，Go 工具通过一组特定的构建模式选项创建一个非 PIC .o 文件(比如 app.o)和一个 PIC 共享库，比如 libmain.so。顾名思义，libmain.so 内部确实有 THE main 功能。

接下来，Go 工具调用编译器驱动程序 gcc 来链接 .o 和 .so 以生成可执行文件，这不一定是 PIE。为简化起见，Go 工具调用的链接器命令如下:

$ gcc -o app.x -L. -lmain -Wl,-rpath=$PWD -fuse-ld=gold app.o

事情是这样的。至少三位专家确认必须使用 Scrt1.o 来链接他们，因为 main 位于 PIC 共享库中。但是，gcc 正在拉出 crt1.o。

我的问题是这是 gcc 错误还是用户的错误。当然，如果用户在上面的链接命令中添加了“-pie”选项，gcc 将改用 Scrt1.o。但是，用户可能会声称，由于他们可能不想要位置独立的可执行文件，因此添加“-pie”可能没有多大意义。

我试图在 gcc 手册中找到适当的信息，但没有成功。在这种情况下，用户是否应该指定“-pie”？或者，是否允许用户制作非 PIE 可执行文件，以便此问题是 gcc 错误？

为了方便起见，这里有一个简单的例子:

$ cat app.c 
int foo(int x, int y)
{
  volatile int z = x;
  return z + y;
}
$ cat main.c 
extern int foo(int, int);
int main(int argc, char* argv[])
{
  return foo(argc, 4);
}
$ gcc -o app.o -c app.c
$ gcc -o main.o -c -fPIC main.c
$ gcc -o libmain.so -shared main.o
$ gcc -o app.x -L. -lmain -fuse-ld=gold -Wl,-v,-rpath=$PWD app.o
collect2 version 4.8.5 20150623 (Red Hat 4.8.5-36.0.2)
/usr/bin/ld.gold --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -dynamic-linker /lib/ld-linux-aarch64.so.1 -X -o app.x /usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64/crt1.o /usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64/crti.o /usr/lib/gcc/aarch64-redhat-linux/4.8.5/crtbegin.o -L. -L/usr/lib/gcc/aarch64-redhat-linux/4.8.5 -L/usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../.. -lmain -v -rpath=/home/aion1223/workspace/shared app.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/aarch64-redhat-linux/4.8.5/crtend.o /usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64/crtn.o
GNU gold (version 2.27-34.base.0.2.el7) 1.12

Answer 1

这里讨论过这个问题:

the gcc bug report

我想 gcc 很清楚给 crt1.o 是正确的行为，因为最终的可执行文件不是 PIE。它似乎根据最终的可执行文件选择 crt1.o。

Andrew Pinski's comment 18

根据评论，gcc 确实并且旨在提供 crt1.o。因此，这不是 gcc 错误。那么，这应该是 gold 或 glibc 问题。