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".
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.
来源：https://stackoverflow.com/questions/2020961/why-would-the-elf-header-of-a-shared-library-specify-linux-as-the-osabi