Re: [bug #24554] Pthreads and Stack overflow in guile (reopen bug 20814?) (guile 1.8.5)

[Neil Jerram]

2008/10/14  <address@hidden>:
>
> I would imagine that --with-threads will not be turned back on until a 1.10.x 
> (or 2.0.0 ?) release of Guile.
>
> My limited understanding of the situation (possibly incorrect):  Using 
> --without-threads changes the sizes of some data structures (I'm guessing 
> they are smaller, with some pthreads stuff #ifdef'ed out), so that code 
> compiled for one way will segfault when linked with code compiled for the 
> other way.
>
> As far as just releasing new packages --with-threads, It's just not possible 
> to go back an recompile all the currently existing packages on already 
> existing systems.

Really?  Isn't that what happens normally in "transitions"?  There are
only 28 packages depending (directly) on guile-1.8-libs.

Or is the issue about non-Debian applications that people have built
themselves?  Does Debian policy require a package's ABI always to stay
back-compatible?

(Another option would be creating new packages with --with-threads
support.  The current guile 1.8 packages are named guile-1.8 and
guile-1.8-libs, and it must be the case that everything currently in
Debian that depends on these does _not_ require support for multiple
threads.  It should be possible to create packages with new names,
e.g. guile-1.8-mt and guile-1.8-mt-libs, that were built
--with-threads, and these would initially have no packages depending
on them.

The problem with that, though, is that the existing and -mt packages
could not coexist, so a Debian user would have to choose between the
existing packages (+ the option of everything that depends on them)
and the -mt packages.)

Regards,
     Neil