Re: scm_cell vs threads build option

[Rob Browning]

Kevin Ryde <address@hidden> writes:

> I gave Rob's new debian packaged 1.8.2 a go and found a bit of a problem
> with scm_cell.  The new packages have threads enabled, where the old
> ones had it disabled, and alas that setting infects the inlined
> scm_cell().  If you built your app against the old and run it against
> the new then it bombs on SCM_FREELIST_LOC doing the different "thread
> key" thingie access.
>
> I guess scm_cell has been inlined that way for a while, but it'd be
> worth thinking about not inlining it, or only inlining for internal
> uses, in the interests of binary compatibility among as many build
> options as possible.
>
> I struck the problem in my own build of guile-gtk, not sure what
> packaged stuff might be affected.  gnome-games seems ok.  Anything using
> smobs probably isn't.

This is potentially bad (for Debian at least).  I'll have to
investigate, but it may mean that I will have to revert Debian's build
for now so that it doesn't enable threads.

If the library ABIs really aren't binary compatible, then I probably
won't be able to re-enable threads in Debian for 1.8 without some
fairly ugly workaround (parallel packages, or similar).

The problem is that Guile 1.8 in Etch was compiled without threads
(due to some serious problems at the time).  So if there is a binary
incompatibility, then I can't re-enable threads now without breaking
everything in stable (Etch) that was compiled against the non-threaded
version.

Of course, it's generally considered a big mistake to produce two
libraries with the same soname and incompatible binary APIs.  Perhaps
Guile should use a different name for the threaded libs if they're not
compatible.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4