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: Tue, 11 Jul 2000 17:12:35 -0600 From: Jeffrey A Law <law@cygnus.com> In message <200007111759.e6BHxfp26885@delius.kettenis.local>you write: > [Sorry folks, tried to send this to gcc@gnu.org instead of > gcc@gcc.gnu.org :-(] > > Here's an analysis of the modules in libgcc.a for GCC 2.95.2 on > i586-pc-linux-gnu. Feel free to put this up on the gcc web pages if > you like (linked to the libgcc.so discussion page or so). > > Based on this analysis, I think the only stuff that should be moved > into a shared libgcc on Linux/x86 is the frame registration stuff > (frame.o) and probably parts of the language-independent exception > handling stuff (libgcc.2[L_eh], i.e. the stuff that ends up in _eh.o). Actually, I *strongly* disagree with any notion that the contents of the two libraries should be different. Every major unix vendor has done this at some point in the last 10 years, and every time it's caused problems. Please, let's not make the same mistakes everyone else did, instead let's learn from them. The interfaces provided by the libraries need to be identical, anything else just makes life a living hell for application developers as well as tool developers. We've been doing it with glibc quite successfully. A typical Linux installation has /usr/lib/libc.a /usr/lib/libc_nonshared.a /usr/lib/libc.so /lib/libc.so.6 where /usr/lib/libc.so is the following linker script: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a ) It works quite well (although from time to time someone manages to replace the libc.so linker scrypt with a symlink to /lib/libc.so, usually with the help of an old version of that braindamaged tool called ldconfig). Of course not all linkers support this nifty trick, and we can't force evrybody to use GNU ld :-(. Now I am open to the idea that there's libgcc.{a,so} that has some set of routines and some other library that has additional routines. However, you have to be very careful about the things you do not include in libgcc -- for example the EH routines, which are the root of most of our recent problems. I'm not sure I understand what you're saying here. Do you mean libgcc.a or libgcc.so (or whatever it's called). I'd say that you should be very careful about what you *do* put in a shared library. There are parts in the current libgcc.a for which it would be very unwise to put them into the shared libgcc.so. If you want the contents of every lib*.so paralleled by a lib*.a, this would imply that you'd put all functions that don't go into libgcc.so will be moved to libgcc2.a (or whetever it'll be called). We can't do self-contained libraries that include copies of those routines, it simply doesn't work. Instead we need libraries which reference libgcc.so (or whatever it's called) to get those routines. Indeed. The EH stuff is the minimal stuff that should go into the shared library we're talking about in these discussions here. Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |