fornwall
commented
8 years ago @iainnicol I saw your post to the bug-gnulib mailing list about rpl_getcwd not working. I guess this is a symptom of it. Have you got any feedback on it?
It would be nice to have a general solution to gnulib bloating code size and enabling wrappers when not needed during cross compilation. One point of view is http://wiki.osdev.org/Cross-Porting_Software#Gnulib:
The GNU portability layer takes the form of a collection of files that everyone copies into their
packages and then neglect to update often. These files are often deeply integrated into the package
(i.e. hard to disable properly). The principle of replacing standard library functions if broken or missing
is not too terribly bad - but Gnulib mixes it with a huge paranoia that the host system is terribly broken
and assumes the very worst when cross-compiling. The result is that when you cross-compile these
ports, huge amounts of compatibility code gets compiled in, and much of this compatibility code does
not even work on unknown platforms. Of particular fun is code that needs to integrate deeply into stdio
internals or when it replaces your printf. The result is that as you port packages, you often find yourself
fixing the same gnulib code over and over (each time subtly different depending on when it was
forked). When you improve your stdio implementation to be more standards-compliant, you find
yourself needing to fix all those gnulib stdio-internals-aware files all over again, because some silly
internal changed.
The solution is to scream in horror at how troublesome and unnecessary this scheme is as obviously
you are capable of implementing a correct operating system. This racketeering scheme has #error
statements that tell you to upstream preprocessor conditionals for your operating system, so they can
relish in even more complexity that didn't need to exist in the first place.
Sortie (http://wiki.osdev.org/User:Sortie) has developed a gnulib policy for his OS
(https://gitorious.org/sortix/pages/Gnulib) that describes how to handle gnulib and it has a long
list of secret autoconf variables that makes gnulib assume everything is perfect.Unfortunately the above link to the collection of autoconf variables seems to be broken now, but if that or some other similar page could be found it would be helpful.
iainnicol
Zile seems to have a problem with paths (zile 2.4.11-1 on Termux 0.21 on both my phone (a Nexus 6p running Android 6.0) and my tablet (a Nexus 9 also on 6.0)
Example, in the default $HOME directory: echo "test text" > foo.txt zile foo.txt
This leads to a blank zile buffer and not the test text. If I then type something and try to save it I get an error "Error writing '/foo.txt'. Read-only file system" indicating that it is thinking I'm trying to edit /foo.txt. This doesn't happen if I use vi, so it isn't a general problem in termux itself.