This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [PATCH] ppc64 LD_PRELOAD tolerance
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Steve Munroe <sjmunroe at us dot ibm dot com>
- Cc: Ulrich Drepper <drepper at redhat dot com>, libc-alpha at sources dot redhat dot com,Roland McGrath <roland at redhat dot com>,Steve Munroe <sjmunroe at vnet dot ibm dot com>
- Date: Fri, 27 Sep 2002 10:59:53 -0400
- Subject: Re: [PATCH] ppc64 LD_PRELOAD tolerance
- References: <OF738A7715.4BCBB688-ON86256C41.004FE0EA@rchland.ibm.com>
On Fri, Sep 27, 2002 at 09:47:56AM -0500, Steve Munroe wrote:
>
> Ulrich Drepper writes:
>
> > No. We are not going to add an own programming language to the
> > LD_PRELOAD handling. If you need a DSO only for 32-bit create a dummy
> > for 64-bit. This is no problem since LD_PRELOAD should never be used
> > lightly; it should always and only be used in invocations of one
> > program. It mustn't be in the environment and exported. LD_PRELOAD is
> > means for temporary work arounds and testing etc. If you need it to get
> > a program running write a shell script wrapper which uses LD_PRELOAD.
> > But that's it.
>
> I wish things where that simple. For example consider the following exerpt
> form doc/README.socksify in the dante package:
>
> $Id: README.socksify,v 1.4 1999/04/26 13:52:33 michaels Exp $
>
> The shell script socksify in the bin directory is meant to aid in
> using socks with already compiled dynamic binaries. This works by
> setting the LD_PRELOAD environment variable to libdsocks. It will
> then wrap all networking-related system calls.
>
> When used the script can socksify a program by simply giving it as a
> parameter to socksify:
>
> socksify ftp
>
> A more permanent solution would be to add the LD_PRELOAD environment
> value to the shell startup files. Then all non-set[ug]id applications
> that are linked dynamically would be socksified.
>
> Lots of people do this. And as is this prevents the execution of the other
> mode for biarch systems (like PPC32/.PPC64). We need a solution.
>
> Is your objection to just the embellishments I offered or to Roland's
> suggestion ($LIB dynamic symbol) as well. It seems that your suggestion to
> "create a dummy for 64-bit" only works when something in the path splits
> the 32- 64-bit libraries (as the files names must be the same).
But these people should be doing something like:
LD_PRELOAD=libdsocks.so.N
And Roland has been saying all along that that should work fine in a
hybrid environment. Only if they do LD_PRELOAD=/usr/lib/libdsocks.so.N
is there a problem; don't do that!
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer