Re: MinGW open-process, take N

[Andy Wingo]

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