This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: prelink ok?
- From: Jakub Jelinek <jakub at redhat dot com>
- To: tong changda <tongcd at hotmail dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Wed, 15 Jun 2005 07:54:32 +0200
- Subject: Re: prelink ok?
- References: <BAY7-F462501E962DCDEB8E323FDAF20@phx.gbl>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Jun 15, 2005 at 11:27:10AM +0800, tong changda wrote:
> Hello everybody
> sorry if not proper to ask here
>
> I use prelink on arm dynamic library and execute file. prelink -av finished
> without warning, but readelf shows some unexpects:
>
> /lib/libavformat.so.1 420b8000-420fb8b8
> 0x00000001 (NEEDED) Shared library: [libc.so.6]
> .....
> 57: 420faacc 32 OBJECT GLOBAL DEFAULT 13 pam_image_format
> 58: 00000000 252 FUNC GLOBAL DEFAULT UND strchr@GLIBC_2.0 (2)
>
> our symbol external is left unsolved, but local symbol are solved the
> address normally,
> I think after prelink there should be no UND symbol,Did I compile the
> library the wrong way?
prelink doesn't change undefined symbols in this way.
All it does is 1) relocate the shared library to a certain fixed address
2) apply relocations 3) prepare things for the dynamic linker, so that if
all libraries and the binary are mapped in the right places and have not
been changed since prelinking, ld.so can skip all the relocation handling
and instead just apply some fixups
The shared libraries must still be usable even when prelinking can't be
used. So e.g. the changing of undefined symbols you are expecting
(why?) certainly must not be done, as otherwise the shared library
or binary wouldn't be usable when prelinking can't be used.
Please read prelink's documentation if you want to know more.
Jakub