Re: global vars and symbol visibility for mips32/elf

[Richard Stallman <rms@gnu.ai.mit.edu>]

    If a shared library defines a function foo, and your program defines a
    function foo, that does not cause any conflict.  Your program's
    definition of foo is used.  If functions in the shared library call
    foo, they will call your program's definition of foo rather than the
    shared library's definition.  In this sense, shared libraries act just
    like archive libraries.

This is not, in general, what archive libraries do.  Archive libraries
do this in the common case where each defined global is in a separate
member.  But if one member defines two different globals, the archive
library does not work this way.  It is good practice, in most
situations, to put each global definition into a separate member, but
it is not universal practice.

If one member defines two global symbols X and Y, you can have a
program which links with no complaint against the shared library, but
would get an error if linked against the archive library.  All the
program needs to do is reference X and define Y as weak.  The archive
library would define Y and thus override the weak definition from the
program.  The shared library would, I expect, let the program override
Y's definition.

I think we should make the shared library work just like the archive
in all cases.

What is needed is a table of implications:
  If symbol foo is referenced, treat symbol bar as strong.
  If symbol bar is referenced, treat symbol foo as strong.
  If symbol quux is referenced, treat symbols foo and bar as strong.
  ...

(In that example, I've assumed that one member defines both foo and
bar, while another member defines quux and references foo.)

This table would selectively override the default behavior, which is
the same as now (each defined global symbol in the shared library acts
as weak).

Given this table, there would be no need to do anything special for
common symbols.  A common symbol in the library could be treated just
like any other definition in the library: use it to resolve an
undefined reference, or if forced by the table due to a reference to
some other symbol.

I don't think this would make linking much slower.  I think it could
be made quite fast by means of a table that parallels the main symbol
table in the library, so that you reference it using the same index
used in the main symbol table, rather than by looking up names,