甜瓜 <littlesweetme...@gmail.com> writes: > I find a problem when upgraded g++ from 4.4.1 to 4.4.2. Original g++ > generates code with "System V ABI", but new g++ generates code with > "Linux ABI". I don't know what difference between them, but the output > .so file from g++ 4.4.2 cannot be used in g++ 4.4.1. > > To describe my problem clear, I have two x86-64 PCs with RedHat Linux. > g++ 4.4.1 is installed in PC1, while 4.4.2 is installed in PC2. > If I copy the executable file compiled by PC1 to PC2, and run "ldd > a.out", it prints the related modules. > But if I copy the executable file compiled by PC2 to PC1, and run "ldd > a.out", it prints error message for "not a dynamic executable". > Therefore, it seem the gcc tool-chain have backward compatibility for > "System V" and "Linux" ABI. > > Could you tell me why g++ changes ABI? and why cannot I find any thing > about it from the changelog of gcc 4.4.2? > Is there a way to specify ABI in gcc command line on x86/64 platform?
This question is not appropriate for the mailing list g...@gcc.gnu.org. It would be appropriate for the mailing list gcc-h...@gcc.gnu.org. Please take any followups to gcc-help or to some non-gcc mailing list. Thanks. This is actually being caused by the linker, which is not a part of gcc. The linker marks the ABI in an executable or shared library by setting the EI_OSABI field in the ELF header, which you can display using readelf -h. The default value, 0, is known as the "System V ABI." The GNU linker will set the EI_OSABI field to ELFOSABI_LINUX if there are any STT_GNU_IFUNC symbols, which are a new feature of glibc. There is no way to change the linker's behaviour from the gcc command line. Ian
