This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Try to solve shared libgcc and glibc


   Date: Fri, 23 Mar 2001 08:51:43 -0800
   From: "H . J . Lu" <hjl@lucon.org>

   On Fri, Mar 23, 2001 at 12:37:36PM +0100, Mark Kettenis wrote:
   > "H . J . Lu" <hjl@lucon.org> writes:
   > 
   > > I am trying to address an issue with shared libgcc and glibc. I can
   > > understand the need for shared libgcc from gcc. But I don't think
   > > the current scheme will work for glibc. I propose the system based
   > > on glibc also provides the shared libgcc as a system library. It is
   > > trivial to build our own libgcc_s.so.0 during the glibc build. We
   > > provide libgcc_s.so as
   > > 
   > > # cat << EOF > /usr/lib/libgcc_s.so
   > > GROUP (
   > > /lib/libgcc_s.so.0
   > > -lgcc
   > > )
   > > EOF
   > 
   > Comments:
   > 
   > 1. This doesn't address the problem with shared libraries re-exporting
   >    symbols from libgcc.a.

   Are you talking about shared libraries linked with -lgcc_s or -lgcc? If 
   they are linked with -lgcc_s, it sholdn't happen. When it happens, that
   means we don't want it in /lib/libgcc_s.so.0. If they are linked with 
   -lgcc, it may be a problem. I am not sure if we can do anything about
   it except for relinking them with -lgcc_s.

I'm basically talking about the current situation where shared
libraries that reference any symbols in libgcc.a will reexport those
symbols.  If you don't think that this is a problem ask yourself why
we have __divdi3, __moddi3, __udivdi3 and __umoddi3 in
sysdeps/i386/Versions.

   > 
   > 2. This means that one has to rebuild glibc whenever stuff is added to
   >    libgcc.

   1. It is not entire necessary. I have a script to rebuild/install
   libgcc_s.so.0 from an installed gcc. But I don't want to make it
   available to everyone. It is way too easy to break your machine
   when libgcc_s.so.0 is wrong.

I cannot follow you here.  How does one update stuff originating from
libgcc that lives in libc.so without having to rebuild it?

   2. We can provide a configure time option to gcc to build/install
   /lib/libgcc_s.so.0, not /usr/lib/libgcc_s.so. But I still think it is
   too risky.

That would indeed be tricky.

   3. Since libgcc_s.so.0 is a system library, it should come from the
   system vendor just like glibc. Build/install gcc shouldn't install
   libgcc_s.so.0 by default. You can build/install libgcc_s.so.0 yourself
   like glibc. But you have to know what you are doing.

Linux vendors will have to privide a libgcc_s package and use their
dependency tracking system to make sure their users have an up to date
version of libgcc installed.

People installing GCC from sources will have to copy the shared libgcc
into /lib (or /usr/lib) manually if they use it to compile any stuff
in / (or /usr).  I fail to understand why this means that GCC
shouldn't install the shared libgcc by default.

   4. You can always configure gcc with --enable-shared=libgcc and pray
   your whole machine will be ok.

As long as installing GCC doesn't overwrite a more recent version of
the shared libgcc, I don't see how things could go wrong.

   > 
   > > We then make libgcc_s.so.0 an auxiliary filter for libc.so. I enclosed
   > > a demo here:
   > 
   > Richard Henderson anticipated just the opposite: Make libc.so an
   > auxiliary filter for libgcc_s.so, such that the libgcc functionality
   > that's currently included in libc.so becomes a "servicable component".
   > 

   I am not sure if it is how the auxiliary filter works. From "info ld":

   `-f'
   `--auxiliary NAME'
	When creating an ELF shared object, set the internal DT_AUXILIARY
	field to the specified name.  This tells the dynamic linker that
	the symbol table of the shared object should be used as an
	auxiliary filter on the symbol table of the shared object NAME.

	If you later link a program against this filter object, then, when
	you run the program, the dynamic linker will see the DT_AUXILIARY
	field.  If the dynamic linker resolves any symbols from the filter
	object, it will first check whether there is a definition in the
	shared object NAME.  If there is one, it will be used instead of
	the definition in the filter object.  The shared object NAME need
	not exist.  Thus the shared object NAME may be used to provide an
	auxiliary filter on the symbol table of the shared object NAME.

	If you later link a program against this filter object, then, when
	you run the program, the dynamic linker will see the DT_AUXILIARY
	field.  If the dynamic linker resolves any symbols from the filter
	object, it will first check whether there is a definition in the
	shared object NAME.  If there is one, it will be used instead of
	the definition in the filter object.  The shared object NAME need
	not exist.  Thus the shared object NAME may be used to provide an
	alternative implementation of certain functions, perhaps for
	debugging or for machine specific performance.

   Making libgcc_s.so.0 an auxiliary filter for libc.so will make sure
   the defintions in libgcc_s.so.0 will be used instead of those in
   libc.so. It will work even if libgcc_s.so.0 doesn't exist. It also
   doesn't matter if your binary is linked against libgcc_s.so.0 or not.
   I don't see how making libc.so an auxiliary filter for libgcc_s.so.0
   will work/do anything more and why my approach won't.

I don't understand "your approach", since you didn't explain how it is
supposed to work, and I am too stupid to figure it out from the code
you provided.  I do understand Richard's approach though since he did
provide an explanation.

You know what?  If you care to explain your approach, I'll try to
explain Richard's.

   > It really is a shame that Ulrich keeps ignoring the problem.  Your
   > rants and patches really don't help if you don't explain *why* they're
   > necessary and *how* they work.
   > 

   What did you mean by that? You don't see the shared libgcc is a problem
   for glibc, do you?

I don't see why it is a problem specific to glibc.  I do think it's
anoying that with GCC 3.0 every shared library will depend on the
shared libgcc, even for plain C.  And I do thing there are better ways
to solve the problems that are being addressed by introducing the
shared libgcc.  I've discussed those in the past on the GCC mailing
lists, but the GCC people thought my solutions were either too
dependent on specific features of the GNU toolchain, or not really
reliable.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]