[parisc-linux] elf/resolvfail

[parisc-linux] elf/resolvfail

[Matthew Wilcox]

Here's what resolvfail does:

static const char obj[] = "testobj1.so";

int main (void) {
  void *d = dlopen (obj, RTLD_LAZY);
  int n;

  if (d == NULL) {
      printf ("cannot load %s: %s\n", obj, dlerror ());
      return 1;
  }
[...]

and it outputs:

cannot load testobj1.so: /home/willy/cvs/glibc-C/elf/testobj1.so: undefined symbol: foo

nm testobj1.so:
                 U foo

but i would have throught that RTLD_LAZY would mean that it didn't have to
resolve foo immediately, only when it was used.  Can someone explain what's
supposed to happen here?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] elf/resolvfail

[Ulrich Drepper]

Matthew Wilcox <matthew@wil.cx> writes:

> but i would have throught that RTLD_LAZY would mean that it didn't have to
> resolve foo immediately, only when it was used.  Can someone explain what's
> supposed to happen here?

Get a box with a working glibc and run

  LD_DEBUG=all /build/dir/elf/ld.so --library-path /build/dir:/build/dir/dlfcn /build/dir/elf/resolvfail


on both.  The output LD_DEBUG provides should help you.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: [parisc-linux] elf/resolvfail

[amodra]

On Sun, May 20, 2001 at 05:22:42AM +0100, Matthew Wilcox wrote:
> 
> but i would have throught that RTLD_LAZY would mean that it didn't have to
> resolve foo immediately, only when it was used.  Can someone explain what's
> supposed to happen here?

What type is foo?  Lazy linking only works for .plt entries, ie. functions.

Alan

Re: [parisc-linux] elf/resolvfail

[Matthew Wilcox]

On Mon, May 21, 2001 at 10:00:03PM +0930, amodra@one.net.au wrote:
> On Sun, May 20, 2001 at 05:22:42AM +0100, Matthew Wilcox wrote:
> > 
> > but i would have throught that RTLD_LAZY would mean that it didn't have to
> > resolve foo immediately, only when it was used.  Can someone explain what's
> > supposed to happen here?
> 
> What type is foo?  Lazy linking only works for .plt entries, ie. functions.

extern int foo (int);

int
obj1func2 (int a)
{
  return foo (a) + 10;
}

18077:  find library=testobj1.so; searching
18077:   search path=/home/willy/cvs/glibc-C:/home/willy/cvs/glibc-C/math:/home/willy/cvs/glibc-C/elf:/home/willy/cvs/glibc-C/dlfcn:/home/willy/cvs/glibc-C/nss:/home/willy/cvs/glibc-C/nis:/home/willy/cvs/glibc-C/rt:/home/willy/cvs/glibc-C/resolv:/home/willy/cvs/glibc-C/crypt:/home/willy/cvs/glibc-C/linuxthreads
        (LD_LIBRARY_PATH)
18077:    trying file=/home/willy/cvs/glibc-C/testobj1.so
18077:    trying file=/home/willy/cvs/glibc-C/math/testobj1.so
18077:    trying file=/home/willy/cvs/glibc-C/elf/testobj1.so
18077:
18077:  file=testobj1.so;  generating link map
18077:    dynamic: 0x40198cd8  base: 0x40188000   size: 0x00010d90
18077:      entry: 0x401887bc  phdr: 0x40188034  phnum:          4
18077:
18077:  checking for version `GLIBC_2.2' in file /home/willy/cvs/glibc-C/libc.so.6 required by file /home/willy/cvs/glibc-C/elf/testobj1.so
18077:  checking for version `GLIBC_2.0' in file /home/willy/cvs/glibc-C/dlfcn/libdl.so.2 required by file /home/willy/cvs/glibc-C/elf/testobj1.so
[...]

18077:  symbol=dlsym;  lookup in file=/home/willy/cvs/glibc-C/elf/resolvfail
18077:  symbol=dlsym;  lookup in file=/home/willy/cvs/glibc-C/dlfcn/libdl.so.2
18077:  binding file /home/willy/cvs/glibc-C/elf/testobj1.so to /home/willy/cvs/glibc-C/dlfcn/libdl.so.2: normal symbol `dlsym' [GLIBC_2.0]
18077:  symbol=__deregister_frame_info;  lookup in file=/home/willy/cvs/glibc-C/
elf/resolvfail
18077:  symbol=__deregister_frame_info;  lookup in file=/home/willy/cvs/glibc-C/
dlfcn/libdl.so.2
18077:  symbol=__deregister_frame_info;  lookup in file=/home/willy/cvs/glibc-C/
linuxthreads/libpthread.so.0
18077:  symbol=__deregister_frame_info;  lookup in file=/home/willy/cvs/glibc-C/
libc.so.6
18077:  symbol=__deregister_frame_info;  lookup in file=/home/willy/cvs/glibc-C/
elf/ld.so.1
18077:  symbol=__deregister_frame_info;  lookup in file=/home/willy/cvs/glibc-C/
elf/testobj1.so
18077:  symbol=__deregister_frame_info;  lookup in file=/home/willy/cvs/glibc-C/
dlfcn/libdl.so.2
18077:  symbol=__deregister_frame_info;  lookup in file=/home/willy/cvs/glibc-C/
libc.so.6
18077:  symbol=__deregister_frame_info;  lookup in file=/home/willy/cvs/glibc-C/
elf/ld.so.1
18077:  symbol=foo;  lookup in file=/home/willy/cvs/glibc-C/elf/resolvfail
18077:  symbol=foo;  lookup in file=/home/willy/cvs/glibc-C/dlfcn/libdl.so.2
18077:  symbol=foo;  lookup in file=/home/willy/cvs/glibc-C/linuxthreads/libpthr
ead.so.0
18077:  symbol=foo;  lookup in file=/home/willy/cvs/glibc-C/libc.so.6
18077:  symbol=foo;  lookup in file=/home/willy/cvs/glibc-C/elf/ld.so.1
18077:  symbol=foo;  lookup in file=/home/willy/cvs/glibc-C/elf/testobj1.so
18077:  symbol=foo;  lookup in file=/home/willy/cvs/glibc-C/dlfcn/libdl.so.2
18077:  symbol=foo;  lookup in file=/home/willy/cvs/glibc-C/libc.so.6
18077:  symbol=foo;  lookup in file=/home/willy/cvs/glibc-C/elf/ld.so.1
18077:
18077:  calling fini: /home/willy/cvs/glibc-C/dlfcn/libdl.so.2

On x86, it never tries to look up `foo' at all.

-- 
Revolutions do not require corporate support.