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] |
On Tue, Jul 11, 2000 at 05:33:05PM -0300, Alexandre Oliva wrote: > On Jul 11, 2000, Ulrich Drepper <drepper@redhat.com> wrote: > > > Every application will be linked against this library and therefore it > > must be available on the root filesystem where there is certainly no > > room for gcc. > > Will this mean I won't ever be allowed to install another release of > GCC without rebuilding glibc? This is insane! No. That is why Ulrich suggested it be a standalone package. > > > In the end you might end up to have an individual configuration for > > each arch/OS/host/target combination. > > This is the only reasonable approach. Can you think for a second of > having the SONAMEs of libgcc.so managed by people other than the > maintainers of ports? They're the ones who can tell when > backward-compatibility is broken for a certain platform. People who define the ABI don't necessarily to have to define the SONAME or maintain the shared library. You can not just simply break the backward-compatibility for libgcc.so since it will be a system library. It has to be controlled by the system. > > > I don't know how to make this clearer, libgcc.so is a system library. > > Is this just because glibc gets symbols from it? Yes. > > AFAIK, the main problem is with changing exception-handling > interfaces. Does glibc actually use these functions? Couldn't we glibc wants to use it in the future. > just arrange for glibc to not be linked with the exception-handling > part of libgcc, since any program that uses them would be linked with > libgcc anyway? No. > > Another option: couldn't libgcc's object files just be folded into > libc.so, without creating the hassle of yet another system library? That is what we do today and it doesn't work very well. If you don't know why, ...... > > > Besides, I have not heard a single convincing argument why libgcc.so > > should be generate as part of gcc. What do you want to achieve? > > We want to solve the very same problem you're trying to solve, but not > with a we-only-care-about-GNU/Linux-issues point of view. > As far as I know, only systems, where the shared C library uses gcc's frame based exception, has this problem. Could you please name the other systems? -- H.J. Lu (hjl@gnu.org)
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |