On Wed, Nov 22, 2006 at 11:57:11AM +0100, Olivier Galibert wrote:
On Wed, Nov 22, 2006 at 11:49:04AM +0100, Patrice Dumas wrote:
> That's not true for numerical models. I don't really underestand what you
> are talking about. When I compile a model with
>
> gcc -static mymodel.o -lnumerical-lib
>
> I don't care at all about system share libraries, this is not a shared
> executable, so no trouble with new system shared libraries. And once more
> for numerical models iconv, locales, and nss are not really usefull.
Actually, given the incompetence of the glibc developpers, you do.
They use shared objects whether you want them or not. You can't
resolve localhost for instance, which is quite annoying for X
applications.
And how do you want to resolve localhost when on one box you use
files for that, on another NIS, on another NIS+, on another LDAP,
on another Berkeley DB, etc.?
Even if you only wanted to put files parsing into statically linked
programs and do the rest dynamically, what would e.g. with
#215283, where FC6 anaconda now writes localhost entry as
::1 localhost.localdomain localhost
instead of 127.0.0.1 and gethostbyname would just fail in that case?
When libnss_files.so.2 is used, this is fixable (and will be fixed
soon), otherwise you'd have to recompile all your statically linked
binaries?
Jakub