[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #24554] Pthreads and Stack overflow in guile (reopen bug 20814?
Re: [bug #24554] Pthreads and Stack overflow in guile (reopen bug 20814?) (guile 1.8.5)
Wed, 15 Oct 2008 14:43:27 -0400
---- Neil Jerram <address@hidden> wrote:
> 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
It's not about non-debian applications. It's about preserving ABI
compatability. Here is more information:
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.