l...@gnu.org (Ludovic Courtès) skribis: > 2. When building natively, surely you’ll find out that some packages > do not build (PATH_MAX!), and that there are assumptions in > hurd.scm and base.scm, such as the fact that GNU/Hurd is a > cross-compilation target and not a native system.
Another can of worms I forgot to mention is <hurd/paths.h>, which assumes that translators live in /hurd, whereas we’ll rather have them in /gnu/store/…/hurd. The recipe for the ‘hurd’ package could change those file names in <hurd/paths.h>. However, translator file names such as “/hurd/symlink” serve as shortcuts to avoid starting a translator for each symlink: <http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libdiskfs/file-set-trans.c#n111>. Thus, with /gnu/store file names for translators, a libc that uses /gnu/store/XYZ/hurd/symlink as _HURD_SYMLINK (e.g., in <http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/sysdeps/mach/hurd/symlink.c>) would prevent the shortcut if it talks to a translator that expects /gnu/store/ABC/hurd/symlink. I think it would work anyway, but would end up starting one instance of /hurd/symlink for each symlink, which is suboptimal. Food for thought! Ludo’.
