This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] ld.so: command argument "--preload"


On 08/31/2018 10:46 AM, David Newall wrote:
> I'm new here, so I'm probably doing this wrong.  Please tell me what I
> should be doing.

The patch looks great, and it's something we don't have implemented.

Thanks! Fulfilling a need is reason #1 to implement something.

Adding HJ to TO:

HJ, did you propose a similar patch at one point?

This change rings a bell and I don't know why we wouldn't have implemented
this unless there was a technical limitation.

> CHANGE
> 
> Add a --preload command argument to ld.so (aka rtld.c)
> 
> RATIONALE
> 
> I worked around a deficiency in a 3rd party binary, via LD_PRELOAD,
> however any sub-process invoked by that binary tried (as advertised) to
> load the library, too.  When I needed to run the (32-bit) binary under a
> 64-bit OS, I found that the sub-processes worked, but elicited an ugly
> error about wrong ELF class.  What I needed was a way of preloading a
> library for only the binary that I was executing, and not for any
> sub-process (e.g. executed via system(3)).
> 
> I feel that a --preload argument is a minor change on top of which the
> LD_PRELOAD environment variable should be built.  That is, there should
> be a way to preload a library without it propagating to all sub-processes.
> 
> Here is my patch.
Your patch exceeds the ~15 lines of legally significant which means we 
need a copyright assignment in place to accept your patch. I don't see 
your name in the copyright assignments list, so I don't think you have
one, but please feel free to correct me if you do.

You can read about the Contribution Checklist here:
https://sourceware.org/glibc/wiki/Contribution%20checklist

The Copyright assignment process is documented here:
https://sourceware.org/glibc/wiki/Contribution%20checklist#FSF_copyright_Assignment

I suggest following 'request-assign.future' which would allow glibc
developers to continue accepting any of your patches from now into
the future. This makes it very easy to accept your patches. The FSF
can complete assignments digitally in many countries around the world
so the assignment process can be very quick and digital only.

If you have any questions, please don't hesitate to contact me off list.
I'm a project steward for the GNU C Library and I'd be happy to answer
any questions you have.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]