public inbox for gas2@sourceware.org
 help / color / mirror / Atom feed
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: ian@cygnus.com
Cc: drepper@cygnus.com, dm@sgi.com, gcc2@cygnus.com, gas2@cygnus.com
Subject: Re: global vars and symbol visibility for mips32/elf
Date: Sat, 10 Aug 1996 17:37:00 -0000	[thread overview]
Message-ID: <199608110037.UAA17547@psilocin.gnu.ai.mit.edu> (raw)
In-Reply-To: <199608092230.SAA07516@sanguine.cygnus.com>

    That turns out not to be the case.  A shared library is not like an
    archive library.  A shared library is a single object.  Everything
    that composes a shared library is linked together.  There is only one
    set of symbols.  There is no way for the linker to form any sort of
    transitive closure operation, because there is no longer any
    distinction between the various object files which compose the shared
    library.

Although this may be how things work now, it is not really a useful
way for things to work.

Dividing an ordinary library into separate members provides two benefits:

* The members you don't refer to, do not take up space in your program.
* The members you don't refer to, do not fill up your program's name space.

The first benefit is not relevant or possible when using a shared
library, but the second is completely applicable.  Linking with a
shared library should give you exactly the same external symbols that
you would get by linking against the unshared library it was made
from.

Even if other people's shared library implementations don't do this
right, ours should do it right.

Doing this right does not require any changes in the shared library
run-time mechanism.  It only requires some way of representing, in the
shared library's symbol table, a division of external symbols into
various "library members".  Then ld can treat as weak any external
definitions which are not in the same "library members" as some symbol
that is referenced.  Each "library member" should have references as
well as definitions; that way, ld can tell that if "library member" A
is referenced, and it references member B, then the definitions in B
are not weak.

With an open-ended format such as ELF, it should not be hard to design
a way of representing this information, which does not conflict with
anything else and will not confuse other linkers.  If ld finds this
data, it should act accordingly; otherwise, it should do what it does
now.  That way, each of our tools is upward compatible.

This will make it possible to turn any unshared library into a shared
library, with no special precautions, and get no change in the
behavior except for sharing of memory.

Since ELF is the format that GNU systems use, it is not crucial to
implement this in formats other than ELF.

Would the people who work on ld please respond?


  reply	other threads:[~1996-08-10 17:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-08-09  2:46 David S. Miller
1996-08-09  5:24 ` David S. Miller
1996-08-09  9:01   ` Ian Lance Taylor
1996-08-09  8:30 ` Ian Lance Taylor
1996-08-09 13:13   ` Ulrich Drepper
1996-08-09 15:30     ` Ian Lance Taylor
1996-08-10 17:37       ` Richard Stallman [this message]
1996-08-10 19:41         ` Ian Lance Taylor
1996-08-10 23:26           ` Jim Wilson
1996-08-11  1:44           ` Richard Stallman
1996-08-13 10:58           ` Ruediger Helsch
1996-08-13 13:36             ` Jim Wilson
1996-08-13 16:06               ` Ruediger Helsch
1996-08-13 19:04                 ` Jim Wilson
1996-08-13 21:02                   ` Richard Stallman
1996-08-14  3:06                     ` Ruediger Helsch
1996-08-14 23:44                       ` Richard Stallman
1996-08-14  0:18                 ` Nick Ing-Simmons
1996-08-14  3:06                   ` Ruediger Helsch
1996-08-15 11:24                   ` H.J. Lu
1996-08-13  9:06 ` Ruediger Helsch
1996-08-13 10:58   ` Richard Stallman
1996-08-13 13:36     ` Ruediger Helsch
1996-08-13 13:36       ` Richard Stallman
1996-08-13 14:40       ` H.J. Lu
1996-08-13 16:06       ` Ulrich Drepper
1996-08-13 16:06         ` Joe Buck
1996-08-13 17:02         ` Rohan LENARD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199608110037.UAA17547@psilocin.gnu.ai.mit.edu \
    --to=rms@gnu.ai.mit.edu \
    --cc=dm@sgi.com \
    --cc=drepper@cygnus.com \
    --cc=gas2@cygnus.com \
    --cc=gcc2@cygnus.com \
    --cc=ian@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).