Re: [PATCH] Fix hanging of popen.test

[Andy Wingo <wingo@pobox.com>]

Hi,

On Sun 04 Jul 2010 22:33, Neil Jerram <neil@ossau.uklinux.net> writes:

> Andy Wingo <wingo@pobox.com> 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...

Andy
-- 
http://wingolog.org/