[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.
Regards,
Mark