Hi, Neil Jerram <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes: >> This breaks ABI compatibility on IA64, but if Guile wasn't usable on >> IA64 (was it?) that's probably not a problem. > > Good point, and I don't think it was completely unusable before, so > this could be an issue. The problems were sufficient to break > Lilypond on IA64, but many simpler programs could have been fine. > > Who is ABI compatibility an issue for? If it's only the distros, > we're probably OK, as I believe they won't have promoted something > that failed "make check". If we change the ABI, we should increase `LIBGUILE_INTERFACE_CURRENT' and set `AGE' to zero because it's not going to be backward-compatible---and we can't do that only for IA64, unfortunately... > For people building their own Guile libs, can we cover this by a > sentence in the next release notes, to say that programs using > scm_i_thread should be recompiled? Programs necessarily access it, through `SCM_I_CURRENT_THREAD', etc. > I'm happy with adding SCM_NORETURN; but why the SCM_API? I don't > think a libguile application should call scm_ia64_longjmp itself, so > do not intend to document it. Right, but `SCM_API' is just `extern' (except on Windows), which is "normal" in such a declaration; and whether declared `extern' or not, the symbol will be exported anyway. Thanks, Ludovic.
