[Top][All Lists]

[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)


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:

Just click through and you can download a tarball.  For example:

There is .xz too.  This service exists for Guile master too:

> 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?

We also have some unrelated problems on MinGW64 due to the 32-bit longs

I will apply your patch though and I look forward to hearing if it works
for you :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]