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 11:24:15AM +0200, Mark Kettenis wrote:
>    Date: Tue, 25 Sep 2001 17:19:33 -0700
>    From: "H . J . Lu" <hjl@lucon.org>
>    Cc: jakub@redhat.com, libc-alpha@sources.redhat.com
>    Content-Type: text/plain; charset=us-ascii
>    Content-Disposition: inline
>    User-Agent: Mutt/1.2.5i
> 
>    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.
> 
> With Jakub's patch every call to __frame_state_for will try to dlopen
> libgcc_s.so.1.

It will try to dlopen only if it is not dlopened already. But it will call
__frame_state_for in libgcc_s.so.1 always.

> As I said above, the dependency is not very strict.  It only kicks in
> in some corner cases.

I'd stress this. glibc will depend on libgcc_s.so.1 only for legacy C++
applications (and only once new DWARF-2 opcodes are added), so IMHO it is
not a big deal to do the dlopen.

	Jakub


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