Bugzilla Bug 17079

There appeared a new balsa-2.0.9 ebuild which contains a possible instability
for most, if not all users. Obviously there is a problem with threading and
aspell, no idea how it is related.
Here's a pointer to my problem on the balsa-list, although it is not directly
helpful: http://mail.gnome.org/archives/balsa-list/2003-February/msg00119.html

Now the problem can be solved in two ways:
- remove "-lc" from lib-dependencies in "/usr/lib/libaspell.la" before
compiling, which works absolutely great for me
- pass "--disable-threads" to configure instead of "--enable-threads"

The new problem is this:
- first option is hard to perform for an ebuild, regarding the systems integrity
and so on, no idea...
- the second solution makes balsa behave somewhat strange with fetchign mail and
the related progress-popup, I certainly don't like it

I'm extremely satisfied with solution 1, it runs absolutely stable on
2.0.8/2.0.9 for more than 2 weeks now, and I'd definitely consider it a better
chocie than the current officially stable 2.0.3 in portage, which has the same
"bug" btw.

I think is should happen for all users, and I'm wondering why I'm the only one
to have suffered these chrashes... might it be related to something special with
libaspell on my system? It makes balsa quite unuseable with all the freezes on
various places.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

interesting. well, i personally don't use balsa so i wouldn't know. Does it
only happen in combination with procmail or is it a more general threading
issue? Maybe we could fix aspell, but aspell is used by quite a lot of packages
and it might do more harm then good. I noticed you didn't get an answer to the
question if this is a balsa or aspell problem, that might be interesting to
find out.

For now i think the best solution is to disable threading. Ok things like
getting mail might be less responsive, but if it improves stability it is the
way to go.

Instability occurs on most placec balsa uses threads, I noticed:
- fetching mail with procmail
- POP errors while fetching mail
- calling "Help" from menu
- clicking URLs in mails

There might be more.
I found the solution in the december archives, I think.
Basicly it's enough to edit the file just for balsa-compilation and restore it afterwards, don't know how dangerous or illegal that might be regarding sandbox-compilation and breaking the emerge process before restoring the file.

disabling threads is certainly a good idea for now, I'll try to clarify issues related to that then, although me myself will still use the solution enabling threads. :)

disabled threads in -r1 and marked that stable x86.

leaving this open for now, so we can have a look at the issue later on when we have some time on our hands. Please keep us updated here if any progress is made on this point (extra info/fixes).

Ok, here's the small update:

I just tried playing around with patching the configure-script, but the order of the "-l..." obviously doesn't affect the linking output, too bad. :)
I should have listened to one of the balsa developers, who stated the issue is very complex and some real linkage-experts couldn't come up with a good solution.

That leaves us to the point, where I'd like to call a sed-command on /usr/lib/libaspell.la" before and after compilation to work around. I can imagine there might be some really big concerns about sandboxes, unredone edits when emerge gets interrupted, and so on. But then there's the question on how grave this might be.

I *could* test if some other packages requiring aspell compile without the "-lc"-dependancy, but that seems to be a lot of work.

Two other ideas:
- is there a way to catch nun-user-called-emerge-interrupts? e.g. by calling a fix-function instant a direct die? Although... it should compile fine, as much as I experienced...
- second option would be to use pspell (or was it ispell?) but that looks like a even worse solution, I think it's not even in portage and how to force it if both exist...

Just a few inspirations. :)

Coming back to this again, after a while:
The only possible workaround without changing the libaspell.la-file temporarily would be to adjust the linking-order pkg-config returns, but that would be an ugly hack.
I'd suggest to simply let threads disabled for now and close this. There might come a version where spelling is optional somewhen, and then one could activate threads for "-spell".

And notice that "--enable-gtkhtml" is not a valid option for the configure-script. It only checks if gtkhtml is there, and then decides on its own. Isn't that risky, in a way?

could you explain in more detail the gtkhtml thing ? You mean we should also
provide a path or something ?

*oops*

First of all I thought the configure script wouldn't allow to choose for or against gtkhtml, I thought it would use it if available on the system. Reason is that it compiled with gtkhtml althought I had "-gtkhtml" in my USE-flags.

Then I went to check with "./configure --help" and saw, it is indeed an option. But why didn't it get recognized? Looked into the ebuild again, and... *doh*
the ebuild uses "--with-gtkhtml" (at least in 2.0.9), but the correct option would be "--enable-gtkhtml". ;)

enable-gtkhtml it is, that was mentioned in a another bug earlier on and got
fixed already (should be at your place also).

threads will stay disabled for now, please do keep us updated if new
developments take place in this area. Thank you for your help.