[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35519: librsvg broken on i686-linux

From: Mark H Weaver
Subject: bug#35519: librsvg broken on i686-linux
Date: Sat, 11 May 2019 04:03:41 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hi Danny,

Danny Milosavljevic <address@hidden> writes:

> But when I use our separate package definitions it fails when building libcore
> (which is the first library for the target compiler).
> Invoke seems to swallow the output, so I have no idea where or why it failed
> (grr).

Hmm.  What makes you think that 'invoke' swallowed the output?  You
might be right, but 'invoke' is used quite widely by now in Guix,
including to invoke 'make' in gnu-build-system, and I haven't seen
reports of it swallowing output.

I looked at the code.  'invoke' calls 'system*' which calls
'scm_open_process' (in libguile/posix.c) with an empty mode string.

In this case, the child STDOUT becomes (current-output-port) from the
parent if (current-output-port) is a "file port", i.e. a Guile port
backed by a POSIX file descriptor, e.g. a file, socket or pipe.  If it's
a Guile port that's not backed by a file descriptor, e.g. a custom port,
soft port, string port, bytevector port, etc, then indeed the child
output will go to /dev/null instead.

(Note that the port returned by 'open-pipe*' when used in OPEN_BOTH mode
is also a soft port and not considered a file port, even though it is
internally backed by two file ports.)

Ditto for STDERR, except that it uses (current-error-port).

So, if 'invoke' seems to be swallowing output, it's probably because it
was called within the dynamic extent of 'with-output-to-port',
'with-error-to-port', 'with-output-to-string', or similar.


reply via email to

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