Re: Has anyone looked at ELF 4.1?

[Ian Lance Taylor <ian@cygnus.com>]

   From: hjl@lucon.org (H.J. Lu)
   Date: Sun, 16 Aug 1998 17:42:55 -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.

You don't have to use symbol versioning.  You can just change the name
of the library in the usual ELF way.  That is easy, and it prevents
any versioning problems due to library code.

If groff once worked, and then broke, then it sounds as though
somebody must have made an incompatible change to the libstdc++
library interface.  Anybody who makes an incompatible change must
change the library version number.  Using the new ELF specs won't save
us from that sort of failure; it is equivalent to failing to increase
the version number in the ELF specs.

What do the new ELF specs give us that we don't get from symbol
versioning and changing library names?

   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)

What precisely do you mean here by C_ABI and C++_ABI?  You presumably
do not mean the version of the library, because there is no need to
record that.

Four bits only gives you sixteen versions, which is not a lot.

   3. ld sets EI_OSABI depending on target if it is not set at the command
   line.

How does ld determine EI_OSABI?

   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.

This seems pointless.  The library version number is already recorded
in the DT_SONAME entry.  If it isn't, then where is it, and how does
ld determine EI_ABIVERSION?

   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.

Why would we want such a thing?

How precisely will this approach help with groff?

I think we have a problem with using multiple libraries which are
linked against different versions of libc.  However, I don't see how
EI_OSABI and EI_ABIVERSION can help with that.

We already have two library versioning schemes: DT_SONAME, and symbol
versioning.  Why do we need a third?  What deficiency in the existing
schemes does it address?

Ian