Re: Portability of executable binaries

From: Michel Bardiaux (mbardiaux_at_peaktime.be)
Date: 11/13/03 

Date: Thu, 13 Nov 2003 15:31:56 +0100

John Reiser wrote:
>>>> How portible are linux compiled executables?
>>>
>
>> In theory, I should still be able to run statically-linked
>> libc4 or libc5 a.out executables from the mid '90s without any
>> trouble. AFAICK, the system call numbers used by the old libc
>> versions are all still available, even if they are deprecated.
>
>
> Yes.
>
>> libc6 is intended to be backward-compatible "forever" (it uses ELF
>> versioned symbols),
>
>
> Yes.
>
> > so there shouldn't be any problems with normal
>
>> dynamically-linked executables.
>
>
> However, there have been serious bugs. Glibc 2.0.1 definitely is _not_
> backward compatible with glibc 2.0, although both claim to be legitimate
> implementations of libc.so.6. [The current version is glibc 2.3.2 or so.]
> There are more members in struct FILE, sizeof(struct FILE) is different,
> and one of the places where it matters is in the handling of explicit
> uses of stderr/stdout/stdin. If the main program does not reference
> any of stderr/stdout/stdin, but shared libraries and/or other dynamic-
> loaded modules do, then you can have an argument about which
> struct FILE ought to be used at runtime. One instance is
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=85994
>
>> Linking statically will probably cause more problems than it solves.
>
>
> True, and this is a troubling deficiency of glibc 2. In particular,
> the static-linked and dynamic-loaded code for locales (dealing with
> environment variables LANG, LC_*, etc.) must match exactly. So,
> if an application static links any part of glibc 2.* (libc6), then
> for reliable execution that application must be 100% static linked
> (no shared libraries or dynamic modules at all), or else must have
> its own application-specific directory(ies) containing all of the
> corresponding shared libraries (libc, libm, libdl, libnsl, libnss*,
> librt, libpthread; even ld-linux.so.2) and use LD_LIBRARY_PATH or other
> dynamic loader machinery to use the correct libraries at runtime.
> This is a lot of hassle, so the current best general practice is
> always to link dynamically to all parts of glibc, and pray that
> there are no more backward-compatibility bugs.
>

Given that:

(1) Although static linking can solve many portability problems, it will
generally contravene the GPL or LGPL license.

(2) There *are* other glibc compatibility issues; e.g. with glibc2.2 the
return codes from snprintf change brutally and incompatibly - but it is
very hard to know at runtime what the situation is!

Here we consider that *every* distro is a different platform. Serious
PITA but by far the safest way.

HaND, 

-- 
Michel Bardiaux
Peaktime Belgium S.A.  Bd. du Souverain, 191  B-1160 Bruxelles
Tel : +32 2 790.29.41

Relevant Pages