[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MinGW open-process, take N
From: |
Andy Wingo |
Subject: |
Re: MinGW open-process, take N |
Date: |
Tue, 12 Jul 2016 16:05:35 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Greets,
On Tue 12 Jul 2016 15:02, Eli Zaretskii <address@hidden> 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
- MinGW open-process, take N, Andy Wingo, 2016/07/11
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/12
- Re: MinGW open-process, take N,
Andy Wingo <=
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/12
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/14
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/14
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/14
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/14
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/14
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16
- Re: MinGW open-process, take N, Andy Wingo, 2016/07/16
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16
- Re: MinGW open-process, take N, Eli Zaretskii, 2016/07/16