Re: A patch for default version and archive

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

   Date: Wed, 15 Nov 2000 17:05:29 -0800
   From: "H . J . Lu" <hjl@valinux.com>

   > However, thinking about it, I see that you have glossed over some
   > issues in your point 2.  You say that the default symbol can be
   > overridden by a definition without a version.  Let us say that we have
   > a reference to symbol (1) "foo" with version "ver1", and we have a
   > reference to (2) "foo".  Let us say that in a shared library we have a
   > definition of (3) "foo" with default version "ver1".  References (1)
   > and (2) will both resolve to definition (3), right?  But now lets say
   > that in a regular object file we have a definition of (4) "foo".  Now,
   > according to your description, (4) overrides (3).  Clearly (2) should
   > resolve to (4).  Should (1) also resolve to (4)?  If (1) does resolve
   > to (4), that implies that a default version (3) can somehow loan its
   > version string to a symbol (4) with the same name but no version.
   > That seems strange.

   I am enclosing a testcase here. For this one, (1) resolves to (4). It
   is not entirely unexpected. We can say

   1. (1) resolves to (3).
   2. Since (3) is the default definition, it can be overriden by (4).

   Think about it, "a default version (3) can somehow loan its version
   string to a symbol (4) with the same name but no version." does make
   sense since a default version can resolve an unversioned reference
   and can be overriden by an unversioned definition.

I'm finding it really hard to buy that.  What this amounts to is that
"foo" version "ver1" is being resolved to "foo".  That wouldn't
normally happen.  It is only happening because of the presence of
another object in the link, which may wind up not even being used,
which happens to define the symbol "foo" with a default version of
"ver1".  That is really strange behaviour--hard to explain and hard to
understand.  When would that behaviour ever be useful?

   > One way to resolve these confusions might be to ban overriding of
   > symbols with default versions--to treat that case as a multiple
   > definition error.  I don't know what that would break.

   It is a multiple definition error today :-).

But you said earlier ``Glibc overrides the default version between
ld.so and libc.so, libpthread and libc.so.''  Which is it?

Ian