为什么共享库的 ELF 标头将 Linux 指定为 OSABI？
我的 Linux 系统 (Fedora 9) 上的所有标准共享库都指定 ELFOSABI_NONE (0) 作为其 OSABI。
这很好 - 但是我从供应商那里收到了一个共享库，其中 ELF 标头中给出的 OSABI 是 ELFOSABI_LINUX (3)。
对于用于 Linux 系统的共享库来说，这听起来不像是一个不合理的值，但它与我所有其他库的值不同 - 所以当我尝试打开这个库时，使用 dlopen()，从我的其他库之一失败，并出现错误“ELF 文件操作系统 ABI 无效”。
我编译了 FreeBSD 实用程序 brandelf.c 并用它将 OSABI 类型更改为 0，现在库似乎可以与其他所有内容配合良好。
我只是想知道 - 为什么你认为这个库被标记为 ELFOSABI_LINUX？我猜他们可能在另一个系统上交叉编译并指定了一些 gcc 标志，导致这个值被设置到 ELF 标头中？我试图实现类似的目标，但无法确定适当的一个或多个 gcc 标志。
我想知道可能的原因是什么，因为这个特定的供应商在没有大量帮助的情况下不会做任何事情，我想说“你可能正在做 X，但这意味着我们必须修改你的库在我们收到它们之后”。
All the standard shared libraries on my Linux system (Fedora 9) specify ELFOSABI_NONE (0) as their OSABI.
This is fine - however I've received a shared library from a supplier where the OSABI given in the ELF header is ELFOSABI_LINUX (3).
This doesn't sound like an unreasonable value for a shared library intended for a Linux system, however it is a different value to that of all my other libraries - and so when I try to open this library, with dlopen(), from one of my other libraries this fails with the error "ELF file OS ABI invalid".
I compiled up the FreeBSD utility brandelf.c and used it to change the OSABI type to 0 and now the library seems to play fine with everything else.
I'm just wondering - why do you think this library is marked as ELFOSABI_LINUX? I'm guessing maybe they cross compiled on another system and specified some gcc flag that caused this value to be set into the ELF header? I tried to achieve something similar but couldn't determine the appropriate gcc flag or flags.
I'd like to know what the likely cause is as this particular supplier wont do anything without a lot of hand holding and I'd like to be able to say "you're probably doing X but this means we have to modify your libraries after we take delivery of them".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
供应商可能在 FreeBSD 上进行交叉编译，或者使用最新的 Fedora 系统，其中任何使用 STT_GNU_IFUNC 的内容都将被标记为 ELFOSABI_LINUX。如果您尝试在 Linux 上使用它，那么将其更改为 ELFOSABI_NONE 应该不会有问题，就像您所做的那样。
Possibly the vendor is cross compiling on FreeBSD or using a very recent Fedora system where anything using STT_GNU_IFUNC will be marked as ELFOSABI_LINUX. If you are trying to use it on Linux there should be no problems with changing it to ELFOSABI_NONE like you have done.