On Thu, Jan 31, 2013 at 3:19 PM, K. Fossil user <ticketpersonnal-fos...@yahoo.fr> wrote: > $ ./configure --prefix=/usr --sysconfdir=/etc \ > --with-openssl=auto \ > --json \ > --markdown > $ make
> ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > bld/http_socket.o: In function `socket_open': > ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking Well yes, using gethostbyname() and getpwuid() mean using dlopen() because that's what the name service switch in glibc does. If glibc were to always use nscd instead then this wouldn't happen. Anytime you need dlopen() you need all the run-time linker/loader machinery, and you need to be prepared to load libraries that need pthreads, and so on. Static linking is only really going to work well if you avoid dlopen() altogether. I don't understand the appeal of a binary that runs everywhere. Or, I do, but that's not easy anymore (and if you need multiple processor architectures then you really can't have this, not on Linux). On Solaris you can achieve that because of the ABI compatibility guarantee, as long as interfaces don't get EOFed on you. On Linux it ought to be the same, but because Linux depends on symbol versioning instead of direct binding, and because symbol versioning is typically added to libraries by the distros rather than by the open source projects themselves... you're at the mercy of the distros. If Linux were to adopt direct binding then all you'd need is common run-paths and SONAMEs, which you basically already get, and then it'd be a lot easier to build a single dynamic-linked executable that runs close enough to everywhere. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users