当我想要共享库时，GCC 输出可执行 ELF 文件

发布于 2024-11-05 07:27:16 字数 585 浏览 4 评论 0原文

我正在尝试使用 i686-elf 交叉编译器在 Cygwin 中构建共享库。代码非常简单：

int add(int a, int b) {
    return a + b;
}

void _init() {
    add(3, 4);
}

我使用以下命令进行编译：

i686-elf-gcc -fPIC -shared -nostdlib core.c -o libcore.so

这应该生成一个共享对象，对吗？但是 GCC 会输出一条关于无法找到 _start 符号的警告，该符号是可执行文件的入口点，而不是共享对象的入口点。此外，readelf 还表示以下内容：

$ readelf -a libcore.so
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  ...
  Type:                              EXEC (Executable file)
  ...

这里出了什么问题？

原文

I'm trying to build a shared library in Cygwin using an i686-elf cross-compiler. The code is very simple:

int add(int a, int b) {
    return a + b;
}

void _init() {
    add(3, 4);
}

I'm compiling with the following command:

i686-elf-gcc -fPIC -shared -nostdlib core.c -o libcore.so

This should be producing a shared object, right? But GCC outputs a warning about not being able to find the _start symbol, which is the entry point for executables, not shared objects. Furthermore, readelf says the following:

$ readelf -a libcore.so
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  ...
  Type:                              EXEC (Executable file)
  ...

What's going wrong here?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

只是我以为 2024-11-12 07:27:16

问题本质上是你的目标是 i686-elf，而没有人为该目标构建共享库。 -Wl,-shared 将为您提供标记为共享库的内容，但是您计划如何在裸机目标上加载共享库呢？

回复收藏 0 原文

放肆 2024-11-12 07:27:16

我相信裸机目标上的 -shared 是无操作（使编译器认为未指定该选项），因此编译器会构建可执行文件。从命令行上的 info gcc ：

'-shared'
    Produce a shared object which can then be linked with other
    objects to form an executable.  Not all systems support this
    option.  For predictable results, you must also specify the same
    set of options that were used to generate code ('-fpic', '-fPIC',
    or model suboptions) when you specify this option.(1)

...并向下滚动查看脚注：

  (1) On some systems, 'gcc -shared' needs to build supplementary stub
  code for constructors to work.  On multi-libbed systems, 'gcc -shared'
  must select the correct support libraries to link against.  Failing to
  supply the correct flags may lead to subtle defects.  Supplying them in
  cases where they are not necessary is innocuous.

I believe that -shared on bare metal targets is a no-op (making the compiler believe the option wasn't specified) and therefore the compiler builds an executable. From info gcc on the command line:

'-shared'
    Produce a shared object which can then be linked with other
    objects to form an executable.  Not all systems support this
    option.  For predictable results, you must also specify the same
    set of options that were used to generate code ('-fpic', '-fPIC',
    or model suboptions) when you specify this option.(1)

... and scrolling down for footnotes:

  (1) On some systems, 'gcc -shared' needs to build supplementary stub
  code for constructors to work.  On multi-libbed systems, 'gcc -shared'
  must select the correct support libraries to link against.  Failing to
  supply the correct flags may lead to subtle defects.  Supplying them in
  cases where they are not necessary is innocuous.

回复收藏 0 原文

~没有更多了~