This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: libc/936: glibc2 - ld.so fails to load a program defining
- To: Zack Weinberg <zack@rabi.columbia.edu>
- Subject: Re: libc/936: glibc2 - ld.so fails to load a program defining
- From: Ulrich Drepper <drepper@cygnus.com>
- Date: 02 Feb 1999 10:02:58 -0800
- Cc: libc-hacker@cygnus.com, bugs@gnu.org
- References: <199902021239.HAA04140@blastula.phys.columbia.edu>
- Reply-To: drepper@cygnus.com (Ulrich Drepper)
Zack Weinberg <zack@rabi.columbia.edu> writes:
> Just got this from the guy with the strcmp() problem, it' a new and
> much less invasive patch. I don't know the dynamic linker well enough
> to evaluate it. Comments?
The patch is bogus. The question is: why do we re-relocate the
dynamic linker again if it is referenced? Roland, do you remember why
you added this? It is certainly no requirement. We could simply
remove the lines
if (_dl_rtld_map.l_opencount > 0)
{
/* There was an explicit ref to the dynamic linker as a shared lib.
Re-relocate ourselves with user-controlled symbol definitions. */
HP_TIMING_NOW (start);
_dl_relocate_object (&_dl_rtld_map, _dl_loaded->l_scope, 0, 0);
HP_TIMING_NOW (stop);
HP_TIMING_DIFF (add, start, stop);
HP_TIMING_ACCUM_NT (relocate_time, add);
}
without consequences.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------