Has anyone looked at ELF 4.1?

[H.J. Lu]

> 
>    From: hjl@lucon.org (H.J. Lu)
>    Date: Mon, 10 Aug 1998 16:54:32 -0700 (PDT)
> 
>    The purpose of EI_OSABI and EI_ABIVERSION is to tag the OS and ABI.
>    I think we should register ELFOSABI_LINUX and define it as 1. It may
>    make many things easier for us. Right now, after I upgrade from
>    glibc 2.0 to 2.1, groff (man) no longer works since the C++ ABI in
>    glibc is changed.
> 
> This should work anyhow, using the mechanisms we already have.  I
> believe it would be a mistake to attempt to characterize library
> versions using EI_ABIVERSION.
> 
> How precisely would you use ELFOSABI_LINUX to fix this problem?
> 

The problem with groff is the symbols in libstdc++ are not versioned.
The result is the new stdin/stdout/stderr defined in libstdc++ have
the linkage for the old stdin/stdout/stderr. I don't know how hard
to add symbol versioning to libstdc++. With more and more commercial
softwares available for Linux while glibc 2.1 is still in beta, the
100% backward binary compatibility is a major concern. I'd like to
address with the new ELF specs.

May I suggest:

1. Add switchs to ld to set EI_OSABI and EI_ABIVERSION.
2. For Linux, set EI_ABIVERSION with C ABI and C++ ABI.

	EI_ABIVERSION = (0xf & C_ABI) | (0xf0 & C++_ABI)

3. ld sets EI_OSABI depending on target if it is not set at the command
line.
4. ld sets EI_ABIVERSION depending on EI_ABIVERSION in the shared
library used to build an ELF binary if it is not set at the command
line.
5. The dynamic linker will check both EI_OSABI and EI_ABIVERSION when
choosing which shared library to load. With that, we can have both 2
libc.so.6 with different EI_ABIVERSIONs in different directories.

Thanks.

-- 
H.J. Lu (hjl@gnu.org)