This is the mail archive of the libc-help@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: Building glibc 2.19 for OS/ABI UNIX - System V


On Thu, Jul 24, 2014 at 6:58 PM, Shaun Jackman <sjackman@gmail.com> wrote:
>> (a) Copy new versions of all the new libraries you need to your
>> system. Rewriting the program header e.g. INTERP and adding DT_RPATH
>> to force the application to search in a special place first. This
>> option is great since you use the dyanmic loader to your advantage to
>> ensure the right libraries are used.
>
> This worked really well! I used PatchELF to modify the dynamic loader
> and the RPATH of the executable. It'll have to be done on deployment
> to each system, because the location of the new glibc is in the user's
> home directory, but it's possible. I don't suppose there's support to
> expand environment variables like ${HOME} in the ELF header, is there?
>
> patchelf --set-interpreter ${libc}/lib/ld-linux-x86-64.so.2
> --set-rpath ${prefix}/lib foo
>
> [patchelf]: https://nixos.org/patchelf.html

Given your deployment restrictions this is likely your best option.
Particularly given that you don't want to require an admin to install
the application.

To answer your other question: there are dynamic string tokens (DST)
you can use.

See: http://man7.org/linux/man-pages/man8/ld.so.8.html

However, IIRC they are expanded only for DT_RPATH, but I'd verify that
they don't also expand for INTERP.

It doesn't seem like a bad enhancement to expand DSTs for INTERP to
allow self-contained deployments like the one you are designing.

Cheers,
Carlos.


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