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: GCC-3.0.1 can't compile Glibc-2.2.4


On Wed, Sep 26, 2001 at 01:57:54AM +0200, Mark Kettenis wrote:
> 
>    It seems to me that it will only happen in libc.so compiled by gcc 3.
> 
> What *exactly* will "only happen in libc.so compiled by gcc 3".

You tell me *exactly* when dlopening libgcc_s.so.1 is useful. I am
kind of slow on this. Pleae give some real examples.

> 
>    Why can't we put a check in glibc such that only the compatible
>    versions of gcc 3 can be used to compile glibc?
> 
> Define "compatible versions of GCC 3".  Assuming that you mean a
> version of GCC 3 that doesn't emit DWARF2 opcodes that aren't handled
> by the unwinder in libc.so: Adding the checks is possible (and in fact
> I already posted a test that does these checks), but running them only
> makes sense after you've built glibc.

Or we ask gcc people to provide a way to tell if the new DWARF2 opcodes
are added.

> 
>    That is __frame_state_for in glibc should be compatible with the
>    gcc 3 used to build it.
> 
> That means that we'll have to upgrade the code in glibc every time GCC
> is changed to emit new DWARF2 opcodes.  Several people have said
> that's undesirable.

Why? Otherwise, how can you give such precompiled libc.so to other
people? How do you know they will have the compatible libgcc_s.so.1
installed? That means glibc is no longer a self-contained library
since it depends on a particular libgcc_s.so.1. If it is what we want,
why do we even bother to add all those new libgcc functions in libc.so?
We just add -lgcc to libc.so when we use gcc 3.x to build glibc. I
thought the whole idea is we could run libc.so without a libgcc_s.so.1.

> 
>    Is that too much to ask?
> 
> I don't know.  Why do you think dlopening libgcc_s.so.1 is not a good
> idea?  Is it just that you fee that it needlessly adds a little
> complexity, or do you have a possible scenario in mind where it will
> fail?

When we do that, we put the libgcc_s.so.1 dependency on glibc.
Unfortunately, libgcc_s.so.1 is not the part of glibc. We have no
control what is in installed libgcc_s.so.1 and if it is installed.


H.J.


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