From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#35519: librsvg broken on i686-linux Date: Sat, 11 May 2019 04:03:41 -0400 Message-ID: <878svd1kp3.fsf@netris.org> References: <871s1ion48.fsf@netris.org> <87h8a2sc6j.fsf@elephly.net> <20190511020026.4d207749@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([209.51.188.92]:44607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPN1A-0005ZI-L2 for bug-guix@gnu.org; Sat, 11 May 2019 04:06:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPN19-0008PH-BD for bug-guix@gnu.org; Sat, 11 May 2019 04:06:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:54506) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hPN19-0008P5-8E for bug-guix@gnu.org; Sat, 11 May 2019 04:06:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hPN17-0005MT-IN for bug-guix@gnu.org; Sat, 11 May 2019 04:06:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20190511020026.4d207749@scratchpost.org> (Danny Milosavljevic's message of "Sat, 11 May 2019 02:00:26 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Danny Milosavljevic Cc: 35519@debbugs.gnu.org Hi Danny, Danny Milosavljevic 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