This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


   From: Ulrich Drepper <drepper@redhat.com>
   Date: 12 Nov 2000 01:44:39 -0800

   And now he even rose to the level of trying to argue
   about the meaning of this field (which he got explained in the past,
   too) although he is unqualified to make ultimate statements since from
   the audience here only HJ and I were present when the decisions about
   this were made.

The output of a standardization committee should be a standard which
other people can read, understand, and agree upon.  It should not be a
small set of people who are specially qualified to make ex cathedra
pronouncements.  If there is no standard which permits others to
implement interoperable tools from scratch, then, in my opinion, the
committee has failed.

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?

   If you want to protect people like this it's your decision.  I cannot
   tolerate this since maybe at some point (just as it could have
   happened now since you already signalled that you see no problems) he
   finds somebody with write access who makes the change.

I was criticizing not your technical answer, but your attitude.  If
your only purpose is to prevent changing the tools to set the EI_OSABI
field, I do not think that answering ex cathedra to people who
actually trouble to cite the standard (or a standard) is the right
approach.

   > That said, I do not think it would be incorrect to set the EI_OSABI
   > field to ELFOSABI_LINUX when the binutils are configured for a
   > GNU/Linux target.

   You apparently have not even tried it.  Go on, do it.  Beside the fact
   that it would incorrectly flag non-conformance every binary you create
   would fail to run.

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.  Not that I doubt that you have
disabled it in some later version of glibc.  But if I can't argue
against it from the standard, and it works on my system, and I don't
know that you are the keeper of magic knowledge, how can I know what
to do?  That is not a rhetorical question.

Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]