bug-guile
[Top][All Lists]
Advanced

[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: dsmich
Subject: Re: [bug #24554] Pthreads and Stack overflow in guile (reopen bug 20814?) (guile 1.8.5)
Date: 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
> 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





reply via email to

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