libc version

[Robert Bonomi]

> From owner-freebsd-questions at freebsd.org  Mon Jun 18 08:21:38 2012
> From: Sergio de Almeida Lenzi <lenzi.sergio at gmail.com>
> To: freebsd-questions at freebsd.org
> Date: Mon, 18 Jun 2012 10:20:09 -0300
> Subject: libc version
>
> Hello...
>
> I upgrade the server from version 8.2 to 8.3, and rebuild all packages..
> it all works...
>
> Then I installed a binary package (8.3) in an old 8.2 ...
> every package works... gnome, nautilus, wget.... about 800 of them
> the only one that does not work is postgesql84-server
> when I try to run it it I got the message:
> /libexec/ld-elf.so.1: /lib/libc.so.7: version FBSD_1.3 required
> by /usr/local/bin/postgres not found
>
> seems that only postgres is check for the libc version???

INCORRECT.  Postgres is jjust the only one of those programs that
_requires_ a 'minimum' version level that is newer than the one
installed.

> is there a compile switch to check for that???

No.

> Of course, if I compile postgres in the 8.2 or upgrade to 8.3 it
> works...

Naturally. "do it right and it will work'.  <grin>

The required _minimum_ version of a runtime library is specified in the 
program source code -- because it uses features that did not exist in
any version prior to that one.

There is *NO* way to tell _at_compile_time_ what version of a runtome
library will be present when the program is executed.

The 'compiled on 8.3' Postgres binary requires a newer version of libc
than exists in 8.2.   Compile on 8.2 and it builds using diferent code
that does not require the newer libc feature.  hence the 8.2-compiled
code works on 8.2.

The solution to your problem, as you found, is to _not_ use 'more current'
binaries in 'down-rev' environments.  "upward compatibility" is almost
always present in a package.  "backward compatibility" is *always* a
crap-shoot.