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: Sat, 15 Jul 2000 11:07:26 -0700 From: "H . J . Lu" <hjl@lucon.org> On Sat, Jul 15, 2000 at 07:48:17PM +0200, Mark Kettenis wrote: > Date: Sat, 15 Jul 2000 10:03:41 -0700 > From: "H . J . Lu" <hjl@lucon.org> > > On Sat, Jul 15, 2000 at 03:20:23PM +0200, Mark Kettenis wrote: > > Date: Fri, 14 Jul 2000 18:31:28 -0700 > > From: "H . J . Lu" <hjl@lucon.org> > > > > BTW, we just need to make sure everything exported from the shared > > libgcc is also exported from libc.so. I think we will be safe then. > > > > That would be an incredibly stupid thing to do, since it means that > > you'd have to recompile glibc whenever things are added to libgcc.so. > > > > That is true. The isse is we need to find a way to make the references > to those exported symbols in libgcc.so dynamic. That is what libgcc.so > is used for. How about we teach ld to check DT_AUXILIARY? It will > be treated as DT_NEEDED for that purpose. ld won't wont propagate > DT_AUXILIARY to anything else. > > Argh! No! The current behaviour of ld to walk the DT_NEEDED list > when resolving symbols from shared libraries has its problems and is > incompatible with at least the Solaris linker. See > <http://sources.redhat.com/ml/binutils/1999-11/msg00037.html> for a I didn't find the original message. Is the original problem solved? I ran into a similar problem with OpenGL. One OpenGL implmenentation is multi-threaded. But it has to work with single thread applications. That means the OpenGL implmenentation has to make sure libpthread.so is always available even if it is used with a single thread application. I had to fix a bug in glibc to make things to work for them. I can ask them to see how they solved the problem. Here is link to the message with details about the origional problem: http://x40.deja.com/getdoc.xp?AN=545891503&CONTEXT=958448712.1788280849&hitnum=29 The "bug" isn't fixed. It's one of those "BUG IN DYNAMIC LINKER" cases where there's a corrupt/inconsistent binary. The dynamic linker is complaining about the fact that there is a version dependency for a library that's not in the applications DT_NEEDED list, and it has every right to do so. The right fix is to stop the static linker from walking the DT_NEEDED list (at least when recording versioning information, but in principle altogether). The old behaviour should probably still be available, when activated by a special switch. > discussion. Adding this for DT_AUXILIARY makes even less sense. If > the library in DT_AXUILIARY is absent everything should still work. > Our proposed use of DT_AUXILIARY is more or less abusing the concept. > It seems to work, but isn't really appropriate. Let's not bias our > tools too much to this particular use. As I said, ld will check DT_AUXILIARY for setting a symbol dynamic. That means you don't need to use "gcc -rdynamic". I will make sure it won't have any other bad side effects. Can't you see that this is even worse than the DT_NEEDED case illustrated above. An object for which we have a DT_AUXILIARY entry is allowed to be completely absent. That's why making libgcc.so a DT_AUXILIARY of libc.so is such a nasty hack. If some functionality is added to libgcc.so (for example support for a new DWARF symbol), it's not guaranteed that programs compiled with a new version of GCC will still run if the appropriate libgcc.so isn't present. > > > there too. Of course this can be postponed until you actually add > > new stuff to libgcc.so. > > I don't like libgcc.so since it will introduce explicit dependency > on libgcc.so and with DT_AUXILIARY, the only thing we need is to > make the references to to those exported symbols in libgcc.so dynamic. > Without libgcc.so, the resulting binaries will run ok with the slightly > older libc.so which has no DT_AUXILIARY as long as the ABI of libgcc > is not changed too much. > > Nasty, isn't it? That's why I said you could postpone explicitly > linking against libgcc.so until the ABI of libgcc actualy changes. > However, as soon as it does, you'll have no other choice. That is what I want to avoid. That can only been done in a limited number of cases. > In principle, there is no need for the shared libgcc.so at all as long > as you don't use exception handling. So perhaps it is possible to > tweak things (using linker tricks and the GCC specs file) to avoid the > explicit dependency on libgcc.so for plain C programs. That won't work since there is no way to tell if any C++ codes exist or not. I can even implement glibc in C++ as long as I support the glibc ABI. It will work fine. Code compiled without -fexceptions doesn't have any frame info to register, and won't call any exception handling functions. So it doesn't need any of the functionality provided by libgcc.so. If you have a certain shared library, say libfoo.so, that's currently compiled without -fexceptions and reimplement libfoo.so in C++, you'll have to link the library against libgcc.so[1]. But any existing programs that were linked with libfoo.so, will continue to work as before. [1] Of course the compiler driver should do this automagically. Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |