Greets, On Tue 12 Jul 2016 15:02, Eli Zaretskii <e...@gnu.org> writes:
> It's hard for me to build Guile from Git, due to the additional > prerequisites that needs. Understood, in that case please note that there is also an automatic build service that runs "make" and "make dist" to make tarballs: https://hydra.nixos.org/job/gnu/guile-2-0/tarball Just click through and you can download a tarball. For example: https://hydra.nixos.org/build/37557639/download/3/guile-2.0.11.238-e1cb7.tar.gz There is .xz too. This service exists for Guile master too: https://hydra.nixos.org/job/gnu/guile-master/tarball > First, I see that you also removed getuid and getgid; I believe we > only talked about removing setuid and setgid. As I said, getuid is > needed to build Guile. Hmm, I don't think getuid is needed to build Guile. Your message from Tuesday said: getuid is used in boot-9.scm, so if it's unavailable, we cannot build Guile without making changes in the Scheme code. I don't know if that convinces you, and I have no practical way of counting their uses in Guile programs outside Guile itself. But in reality the getuid is of this form: (define (load-user-init) (let* ((home (or (getenv "HOME") (false-if-exception (passwd:dir (getpwuid (getuid)))) file-name-separator-string)) ;; fallback for cygwin etc. (init-file (in-vicinity home ".guile"))) (if (file-exists? init-file) (primitive-load init-file)))) So, no problem. I would be happy to look at another patch that adds them if it turns out that you need them (and sets HAVE_GETUID etc). But, I don't think that leaving them out will hurt anything. > The only other issue I see is the type of the value returned by > start_child, and as result by scm_open_process. On Windows, the value > returned has the type HANDLE, which is actually a pointer in disguise. > I used intptr_t for that, but you changed it to just int. This will > not work in 64-bit MinGW builds, where a pointer is a 64-bit type. I > think we should go back to intptr_t, and also change the conversion to > the value returned by scm_open_process, since scm_from_int will AFAIK > not support 64-bit integer types. Note that the MinGW waitpid > implementation also expects to get a valu that is interpreted as a > handle. Hummmm, I don't know, there are a number of other things in that file which treat PIDs as ints (scm_waitpid, scm_getppid, etc etc etc). I think that would need to be another patch that adds scm_from_pid_t and scm_to_pid_t and so on. And then what is this? http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/12235 We also have some unrelated problems on MinGW64 due to the 32-bit longs there. I will apply your patch though and I look forward to hearing if it works for you :) Andy