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] |
From: Alexandre Oliva <aoliva@redhat.com> Date: 13 Jul 2000 18:35:37 -0300 On Jul 11, 2000, Alexandre Oliva <aoliva@redhat.com> wrote: > Why, then, should glibc people take over the creation of this shared > library for GNU/Linux systems? Now here's one additional, interesting problem. Assume libgcc is a shared library. It has obviously been linked with some version of libc, given that it uses symbols from libc. This means it will have a dependency on some particular libc SONAME encoded in it. That isn't necessary per se. You can have undefined references in a shared library. Now think of glibc: since it uses libgcc, it will also have some particular libgcc SONAME encoded in it. But libgcc already depended on libc, so we have a circularity. No big deal: each library will only be loaded once, and everything is fine, right? Despite the minor problem of how to bootstrap this situation. The bootstrapping problem is solvable with DT_AUXILIARY. If libc contains a DT_AUXILIARY entry for libgcc, instead of an ordinary dependency (DT_NEEDED), libc will only use libgcc if it does exist. This means that libc itself would still have to contain copies of the stuff from libgcc that it explicitly exports now, but these could become dummy versions in the long run. But there's a major problem too. What if I decide to upgrade one of GCC or glibc. What now? New programs I create will depend on the most recent libgcc and glibc, but one of the libraries (the one that was not updated) will depend on the older version of the other. So, if I had upgraded GCC, I'd have two different, potentially incompatible versions, of libgcc loaded into the same process. I'm afraid this may not work. That's why the initial message on the gcc lists where the GCC devlopers announced their intention to turn libgcc into a shared library worried me so much. The current libgcc.a contains some stuff that IMHO isn't suitable to put into the shared libgcc. Tightly controlling the libgcc.so ABI is extremely important. The SONAME of libgcc can *never* change (at least not without changing the libc SONAME too) on Linux and the Hurd. On the bright side these systems use the complete GNU toolchain which means that we have a lot more tools to avoid this than other platforms. This discussion has far too much focussed on the question who'll have to build the shared libgcc. And that part of the discussion hasn't been terribly productive. And actually building a shared libgcc *before* the GCC team is committed to mainting binary compatibility of the stuff we're going to put into it is pointless. Instead I'd like to start working with the GCC team on establishing an ABI for that shared libgcc. I could sure use some assistence on that from GCC developers interested in Linux. Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |