This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
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