---- Neil Jerram <[EMAIL PROTECTED]> wrote: > 2008/10/14 <[EMAIL PROTECTED]>: > > > > 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
