This is the mail archive of the
mailing list for the glibc project.
Re: Building glibc 2.19 for OS/ABI UNIX - System V
- From: Shaun Jackman <sjackman at gmail dot com>
- To: "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: libc-help <libc-help at sourceware dot org>
- Date: Thu, 24 Jul 2014 12:44:00 -0700
- Subject: Re: Building glibc 2.19 for OS/ABI UNIX - System V
- Authentication-results: sourceware.org; auth=none
- References: <CADX6M3qF-6Wd25Pn2Aa_GjdtGaG6Owp=hieR=TYpnXxSvtSbtA at mail dot gmail dot com> <CAE2sS1gWG3z5Q7VhoaH4Lf0UgOC0wjy4Fs4gt1cD5stdOs2aFw at mail dot gmail dot com> <CADX6M3o67SvrNT6LVeA8LCWgqFAWP4jO1EoW8+S0JymhtP2XGw at mail dot gmail dot com> <CAE2sS1h74HZRZJxoL+AzzZbZZBhqRBmxSEG3+jnJ1MNckP06KQ at mail dot gmail dot com>
- Reply-to: Shaun Jackman <sjackman at gmail dot com>
On 24 July 2014 12:21, Carlos O'Donell <email@example.com> wrote:
> On Thu, Jul 24, 2014 at 3:14 PM, Shaun Jackman <firstname.lastname@example.org> 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