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 patch for default version and archive


   From: Ulrich Drepper <drepper@redhat.com>
   Date: 14 Nov 2000 09:50:49 -0800

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

   > One is to make it possible to specify the version of a symbol in a
   > .o file rather than requiring a version script when building a
   > shared object.  The other is to simplify the implementation within
   > the existing GNU linker code, except that that turned out to be a
   > mistake, since it actually makes the implementation more complex and
   > harder to understand.

   Actually no.  The version script serves mainly the purpose of hiding
   symbols from not being exported.  This was before the introduction of
   the .protected and .private attributes.  Today we would do it
   differently.

What I am saying is that if we did not have @ symbols, we could set
symbol versions only in the linker version script.  My understanding
is that that is how it works on Solaris.  Solaris does not have @
symbols.  Instead, you specify a symbol version in the linker version
script when you create the shared library.  Is that not true?

   > If we eliminated the @ symbols,

   You mean "eliminating the version script"?  The @ symbols cannot be
   eliminated.

Well, they can if the version script is used to set symbol versions.
My understanding is that the @ symbols are there to make life simpler
for library maintainers, since otherwise they have to maintain two
separate pieces of information.

   > What I think we really need to do is to write down the semantics of
   > versioned symbols.

   I did this quite some time ago.  Don't know whether it's to the level
   you want but it's documented.

Where is this documentation?

   > It's impossible for third parties to adjudicate them, because nobody
   > knows what is supposed to happen.  So I think that arguing over the
   > patch is putting the cart before the horse.

   Not really.  What you see HJ trying to do is extending the versioning
   handling in areas which it was not used before.  If you feel that
   already the existing implementation is problematic you should be
   completely opposed to any further extensions given there are other
   solutions for the issues which motivated these changes.

I don't have an opinion about HJ's patch.  But I don't know why you
say ``not really.''  I'm saying that if we understand the semantics of
versioned symbols, we will know whether HJ's patch is right or wrong.
I'm sure you're right that he is extending versioning to new areas.
If we know the semantics, then we know whether his extension is
correct or not.  I think you have been saying that we shouldn't do it
because we don't know what it means.  I'm saying that we should
understand what it means.

Ian

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