| Summary: | env-update don't process LD_PRELOAD correctly | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Nguyen Thai Ngoc Duy (RETIRED) <pclouds> |
| Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Patch against 2.0.50-r6 | ||
|
Description
Nguyen Thai Ngoc Duy (RETIRED)
2004-05-05 04:19:13 UTC
Created attachment 30771 [details, diff]
Patch against 2.0.50-r6
You're going to need to explain more here. LD_PRELOAD isn't a colon-separated variable, it's space-separated. See ld.so(8) What behavior are you trying to achieve? Re-assigning to portage team since env-update belongs to them. yeah, like aron said, you're going to have to give a useful reason for why LD_PRELOAD should even bothered being parsed seeing as how it'll rarely get used by most people Yes, my mistake. LD_PRELOAD is not colon-separated. And it's rarely used. But it is used somewhere (xvnkb, libtrash ...). Imagine the scenario that somesone sets two LD_PRELOAD in env.d and it doesn't work as expected. env.d is mostly used by portage packages to install environment pieces so that the final environment can be put together something like LD_PRELOAD is used on a per-app basis and *never* on a system wide basis so, unless there is a real need for it (which has yet to be demonstrated) LD_PRELOAD should not be in a global env |