[Top][All Lists]

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

Re: [PATCH] Fix hanging of popen.test

From: Andy Wingo
Subject: Re: [PATCH] Fix hanging of popen.test
Date: Sat, 17 Jul 2010 13:57:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)


On Sun 04 Jul 2010 22:33, Neil Jerram <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>> This has been an on-and-off issue:
>> 02fcbf78b27788c03563e5c3d297a4cd469ce562, and
>> 04af4c4c5221c082905d52eb5ad3829ed681d097.
> Right.  The commit (4f99a499197b592a9a3060de2205531852f4f94) that
> Patrick McCarty identified (with git bisect) is another very similar
> case.

I think I fixed this one again.

> The general problem is that any #:use-module or (@ ...) that indirectly
> pulls in srfi-1, in any code that is run as part of Guile startup, will
> cause the build to fail when doing the snarf-check-and-output-texi,
> because libguile-srfi-srfi-13-14-v-4 hasn't been built at that point.
> But if the developer concerned happens to have a compatible
> libguile-srfi-srfi-13-14-v-4 and libguile installed in /usr/lib or
> /usr/local/lib, the build may pick those up and so mask the problem.
> Is there a reason why we don't just move all the SRFI C code into the
> core libguile?  I think that would be a general fix.

I agree. They should probably still be their own shlibs, but built at
the same time as libguile. Then we make snarf-check-and-output-texi
depend on the libs being built, as necessary.

Though I would hope that with time we can remove the need for these
shlibs, instead mostly implementing srfis in scheme, and using the
dynamic FFI as needed...


reply via email to

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