iconv az iconv ellen (Kramer contra Kramer)

Pontosabban mondva: ha van egy /usr/local/include/iconv.h meg egy /usr/include/iconv.h,
akkor ki fog nyerni? Mondjuk egy PHP fordítás során?

Nyilván az egyik a libc része (libc6-dev), a másik a külön telepített libiconvé.

Gondolom, az természetes, hogy semerről sem kompatibilisek... a libc ilyen szimbóleumokat exportál:
iconv
iconv_close
iconv_open

a /usr/local/lib/libiconv.so meg ilyeneket:
_fini
_init
_libiconv_version
iconv_canonicalize
libiconv
libiconv_close
libiconv_open
libiconv_open_into
libiconv_set_relocation_prefix
libiconvctl
libiconvlist

Szerk: Mondjuk az lehet, hogy ha lenne /usr/local/lib64/libiconv.so, és a PHP-fordítás rá is találna, akkor ez se lenne gond...

Csodás dolgok vannak a programozásban, az már biztos;)
Adott esetben megesik, hogy különböző időben és különböző beállításokkal fordított komponenseket kellene működő rendszerré integrálni.

Például ha én azt gondolom, hogy linuxban nincs is szükség külső libiconv-ra, mert a libc bizonyára tartalmaz egy tök jó iconv funkcionalitást, akkor esetleg szembejön velem egy /usr/lib/gdm/gdmgreeter nevű komponens, akinek mégis függősége a libiconv.so.2

Szerk: Ami pedig azért van, mert sok évvel ezelőtt az libxml2-t külön iconv-val fordítottam. (Vagyis a configure meglátta, hogy van /usr/local/lib/libconv.so, és használatba is vette.)