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

Glynn Clements glynn.clements at virgin.net
Sat Jan 10 22:09:06 EST 2004

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

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

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>

More information about the grass-dev mailing list