This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Date: Mon, 17 Jul 2000 09:13:20 -0700 From: "H . J . Lu" <hjl@valinux.com> Cc: Geoff Keating <geoffk@cygnus.com>, kettenis@wins.uva.nl, drepper@cygnus.com, law@cygnus.com, rth@twiddle.net, libc-hacker@sourceware.cygnus.com, gcc@gcc.gnu.org Content-Disposition: inline User-Agent: Mutt/1.2.2i Content-Type: text/plain; charset=us-ascii On Mon, Jul 17, 2000 at 05:59:22AM -0300, Alexandre Oliva wrote: > On Jul 14, 2000, Geoff Keating <geoffk@cygnus.com> wrote: > > > [aoliva said:] > > >> Despite the minor problem of how to bootstrap this situation. > > > You can have circular dependencies involving libc. > > Yup. I was talking about how to *create* the libraries in such a way > that each one uses the appropriate SONAME to refer to the other. As I > said, no big deal, it just has to be done carefully. > I am doing some experiments on the shared libgcc. I have added -Wl,--auxiliary,libgcc.so.3 when building my libc.so. I created a shell script, updatelibgcc. updatelibgcc takes CC and slibdir from environment to build/install libgcc.so.3. It seems to work so far. One interesting thing I noticed that libgcc.so might not be needed at all under Linux. I don't like the explicit dependency on libgcc.so. Can someone tell me if there is a case --auxiliary libgcc.so.3 is not enough for Linux? I may have missed something. Let me refresh your mind: 1. We have __deregister_frame_info, __register_frame_info, __frame_state_for, etc. in libc.so. 2. A single copy of these functions must be used in every program. 3. It might be necessary to change the implementation (while maintaining backwards compatibility) of these functions to support new versions of GCC. This implies that the single copy mentioned above must be the most recent copy. 4. We don't want to force everybody to recompile or even upgrade libc whenever they install a new version of GCC. The only reliable solution that has been found thus far is putting these functions in a shared library that can be upgraded (in principle when installing a new version of GCC) whenever needed. Now if point 3 above includes adding any new interfaces, having that shared library as a DT_AUXILIARY of libc.so isn't enough. Any objects that make use of that new functionality (presumably because they have been compiled with the new GCC) will have to be explicitly linked with that shared library. The EH frame info issue isn't the only problem with the current libgcc.a that might be solved by introducing a shared libgcc. Right now symbols from libgcc.a that are used in code in a shared library (say libfoo.so) are usually reexported from that shared library. This means that binaries linked against libfoo.so that also need those symbols, contain undefined references to those symbols. Now if you change the implementation of libfoo.so such that it doesn't need those symbols from libgcc.a anymore and install this new version (that's otherwise supposed to be still binary compatible) your program won't run anymore. The solution proposed by the GCC folks is simply to put everything in libgcc.a into libgcc.so and link every program or shared library with libgcc.so. This indeed guarentees that you never see this problem, and is likely to work on most platforms that support shared libraries. Unfortunately this introduces an explicit dependency for every program on yet another shared library. There have been several people who said they didn't like that, myself included. Having to distribute a shared library with all binaries is a PITA and might lead to people statically linking their programs to avoid this. There also may be of performance penalty with using the libgcc functions from a shared library I think that with on Linux and the Hurd, with the current GNU tools we can do a little better. The reexportation problem can be controlled using STV_HIDDEN/STV_PROTECTED. Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |