Re: A symbol version patch for glibc 2.x compatibility

[Ian Lance Taylor <ian at zembu dot com>]

   From: Ulrich Drepper <drepper@redhat.com>
   Date: 12 Nov 2000 10:25:22 -0800

   Ian Lance Taylor <ian@zembu.com> writes:

   > Where is the standard which we can read to understand the proper
   > meaning of EI_OSABI?  The one which says that it would actually be
   > incorrect to set the field to ELFOSABI_LINUX on a GNU/Linux system?

   Even the text which was quoted says the field is used to discriminate
   files with OS specific interpretation.

But it doesn't say that it is incorrect to set EI_OSABI to some other
value.  It only says that it specifies the interpretation of flags and
values with platform specific meanings.  If a binary has no flags and
values with platform specific meanings, then there is no obvious
reason why EI_OSABI can not have any value.

I'm willing to believe that the intention of the committee was that
setting EI_OSABI is incorrect if a binary uses only standard flags and
values.  But I don't read that from the actual text.

   > Just for fun, I did try it, and it worked fine, on Red Hat 6.1 using
   > Linux 2.2.12-32 and glibc 2.1.3.

   Try again, but this time let ld.so do the work.  The kernel is very
   weak in that it tests only very few fields.  Run ldd on your new
   binary or generate a DSO.

Yes, ldd appears to reject the binary, reporting ``not a dynamic
executable''.  I would have thought that ld.so was involved even in
the simple case, since it links in the C library.

Ian