1/ GLibc and linux symbols versionning issue then...
OK, thanks.
2/ runs everywhere:
I mean, it should run in every plateform... but not cross platform of course.
It is not about java bytecode thing... :D
For example, if someone do fossil compilation with i386, then ALL i386 linux
should be able to run fossil with no changes.
However, as you said it, we can't deal with that... Just too bad...
Best Regards
K.
Nico Williams 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
