[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Neil Jerram
Subject: Re: [bug #24554] Pthreads and Stack overflow in guile (reopen bug 20814?) (guile 1.8.5)
Date: Tue, 14 Oct 2008 22:48:14 +0100

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]