Re: [PATCH][BZ 17251] Calculate RPATH $ORIGIN from absolute path

[Brennan Shacklett <bpshacklett at gmail dot com>]

On Fri, Dec 12, 2014 at 2:44 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 08/12/2014 06:16 PM, Brennan Shacklett wrote:
>>
>> I used the implementation of dl_realpath from sysdeps/tile/dl-runtime.c as
>> the
>> generic implementation, and extended it with lstat and readlink in the
>> linux
>> version. This means the bug is still present on other systems than linux
>> (the
>> generic implementation only returns an absolute path, it doesn't do
>> anything
>> with symlinks), but if there is a way to get the generic version to follow
>> symlinks on all systems please let me know.
>
>
> You use PATH_MAX in the generic code which is, I believe, not available on
> Hurd.
>
> I'm also not sure if the current behavior is buggy.  Maybe it does not
> compose well, but in some scenarios, it is exactly what is needed. Applying
> this patch could break existing programs.
>
> --
> Florian Weimer / Red Hat Product Security

Sorry for the late reply, got caught up in the holidays and the
beginning of the quarter. I can't deny that changing the behavior
could potentially break existing applications, so would it possible to
have glibc search both locations, and document the deprecation of the
current (no patch) behavior? If that isn't possible some documentation
should probably be added regardless, because when I ran into this I
found it extremely confusing and there are no resources to dictate the
correct behavior. I think the biggest problem with the current
behavior is that symlinking the library from another directory means a
choice has to be made between a correct RPATH for the symlink or a
correct RPATH for the original library, because if $ORIGIN is used one
RPATH cannot work for both. If you can see a way forward for working
this into glibc I'll gladly fix the PATH_MAX issue.

Thanks,
Brennan