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

[<dsmich@roadrunner.com>]

---- Neil Jerram <neiljerram@googlemail.com> wrote: 
> 2008/10/14  <dsmich@roadrunner.com>:
> >
> > 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?

It's not about non-debian applications.  It's about preserving ABI compatability.  Here is more information: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi

In any case, Rob Browning is the one who knows what can (and can't) be done.

> (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.)

Yes.  It's gets complicated quickly.

-Dale