[GRASS5] GRASS and libc2.2/libc2.3 portability problem

[Glynn Clements]

Markus Neteler wrote:

> It seems that I discovered a small (?) portability problem in GRASS 5.3/5.7:
> 
> - GRASS compiled on Redhat9/GLIBC_2.3 as network installation (NFS)
> - using this GRASS binary on Redhat7/GLIBC_2.2 leads to an error:
> 
> baez:lib[264.8] ldd libgrass_gis.so
> ./libgrass_gis.so: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./libgrass_gis.so)
>          libgrass_datetime.so => /mpa_sw/ssi/BIO/software/GRASS5.3/grass5bin_cvs/grass53/lib/libgrass_datetime.so (0x40089000)
>          libz.so.1 => /usr/lib/libz.so.1 (0x40091000)
>          libm.so.6 => /lib/libm.so.6 (0x400ae000)
>          libc.so.6 => /lib/libc.so.6 (0x400d1000)
>          /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Yep. In general, a binary (executable or shared library) requires the
specific major version of each of its dependencies for which it was
compiled.

GNU libc 2 has its own versioning mechanism, using versioned symbols. 
Rather than incrementing the major version number every time an
incompatible change is made, they provide a new version of each
applicable function, but also keep the old version(s). When linking
against libc, the newest version is used.

The end result is that programs which were built for a particular
version of glibc can use that version or any later version; they can't
use an earlier version.

If you want binaries to be portable, use the oldest OS version that is
practical. If you use the latest version, the binaries are unlikely to
run on anything else (this is especially true for RedHat, who seem to
be more willing than other distributions to use the very latest
versions).

BTW, although other libraries don't generally use versioned symbols, a
similar issue applies. When a distribution switches to a later version
of a given library, they often provide the previous version as well
(usually in a separate "compatibility" package).

-- 
Glynn Clements <glynn.clements at virgin.net>