Hi, On Sun 04 Jul 2010 22:33, Neil Jerram <n...@ossau.uklinux.net> writes:
> Andy Wingo <wi...@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/
