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]
Other format: [Raw text]

Re: Performance problem of dlopen


On Thu, Oct 24, 2002 at 08:26:09AM -0700, H. J. Lu wrote:
> On Thu, Oct 24, 2002 at 03:58:28PM +0200, Jakub Jelinek wrote:
> > On Thu, Oct 24, 2002 at 06:48:15AM -0700, H. J. Lu wrote:
> > > On Thu, Oct 24, 2002 at 02:36:18PM +0200, Jakub Jelinek wrote:
> > > > There is one thing which ld.so can do better (it is even implemented
> > > > in ld.so, but disabled for now because e.g. librt.so depends
> > > > on the old behaviour) - ATM if symbol lookup encounters a weak symbol,
> > > 
> > > I kept hearing librt.so dpend on it. Do we have a testcase in glibc
> > > for this?
> > 
> > Actually, with current librt.so containing:
> > GROUP ( /lib/libpthread.so.0  /lib/librt.so.1 )
> > it shouldn't be a problem for newly compiled programs. Programs with just
> > DT_NEEDED librt.so.1
> > DT_NEEDED libc.so.6
> > are screwed up, because for symbol lookups the order will be librt.so.1,
> > libc.so.6, libpthread.so.0.
> 
> Well, I thought that change was for a different bug, which was
> indepdenent of the weak/strong issue. That is
> 
> GROUP ( /lib/libpthread.so.0  /lib/librt.so.1 )
> 
> is needed regardless if we make weak == strong or not.  Let me ask it

You're right, __libc_current_sigrt{min,max} is strong in libc.so too.
Cancellable syscalls in libpthread.so on the other side are weak like
in libc.so (ie. again a reason why libpthread.so must come before libc.so
in the search path).
Where it could matter is e.g. pthread_mutex_{,un}_lock, which is strong
in libpthread.so and weak in libc.so.

	Jakub


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