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 24 July 2014 12:21, Carlos O'Donell <carlos@systemhalted.org> wrote:
> On Thu, Jul 24, 2014 at 3:14 PM, Shaun Jackman <sjackman@gmail.com> wrote:
>> Hi, Carlos. Thanks for your quick response. Yes, it does work as
>> expected when I use the newly built loader with the newly built glibc.
>> I can't unfortunately replace the system's default loader in /lib, and
>> there's no environment variable equivalent of `LD_LIBRARY_PATH` that I
>> know of to set the default loader.
>
> That is correct, there is no environment variable that sets the dynamic loader.
>
> The kernel selects it solely on the INTERP program header of the binary.
>
>> Is it possible to build glibc 2.19 with an OS/ABI of UNIX - System V?
>
> Yes, but that's not the problem, and it won't help you.
>
>> If not, is there a component of my toolchain (Linux headers, binutils,
>> glibc) that I can downgrade to an earlier release that will build a
>> UNIX - System V glibc?
>
> This is an X Y problem. Why don't you start by explaining what's wrong
> and why you want to upgrade the core runtimes?

I'd like to run a binary executable that was compiled on a newer
system (Ubuntu 14.04) on an older system (CentOS 5.10). To that end,
I'm compiling glibc 2.19 on the older system (CentOS 5.10). I realize
that the short answer is probably "Don't do that". All the same, call
it a learning experience for me. If it doesn't work and can't work,
I'd like to learn first hand why it doesn't work.

The current problem I'm facing is the error message `ELF file OS ABI
invalid` because the `libc-2.19.so` that I've compiled on CentOS 5.10
uses an ABI unsupported by the system's loader `/lib64/ld-2.5.so`. Is
it possible to get past this without using a newer loader?

Using a newer loader, although possible, would make running the new
executable(s) pretty cumbersome. I could either wrap all the new
executables in a shell script that runs the new loader, pretty ugly,
or I could patch the ELF header to specify the new dynamic linker (the
effect of `ld --dynamic-linker`). I'd prefer to use the old loader, if
possible.

Cheers,
Shaun


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