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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
