Abdelrazak Younes wrote:
> Hum, maybe the problem is in our side and not boost. This comment and
> code in frontends/Dialogs.cpp seems suspicious to me:
Yes, once again a static variable.
>
> // Note that static boost signals break some compilers, so this wrapper
> // initialises the signal dynamically when it is first invoked.
> template<typename Signal>
> class BugfixSignal {
>
> Is it possible that boost::signal changed and that this BugfixSignal is
> not the right fix anymore?
>
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
> Anyway, maybe the signal disconnection should take the BugfixSignal into
> account in some way?
>
> Abdel.
>
--
Peter Kümmel
Index: src/frontends/Dialogs.cpp
===================================================================
--- src/frontends/Dialogs.cpp (revision 19081)
+++ src/frontends/Dialogs.cpp (working copy)
@@ -37,7 +37,7 @@
Signal & operator()() { return thesignal(); }
Signal const & operator()() const { return thesignal(); }
-private:
+//private:
Signal & thesignal() const
{
if (!signal_.get())
@@ -51,7 +51,7 @@
namespace {
-BugfixSignal<boost::signal<void(string const &, Inset*)> > hideSignal;
+BugfixSignal<boost::signal<void(string const &, Inset*)> > *hideSignal = 0;
}
@@ -63,15 +63,18 @@
// is called from some inset destructor if the cut stack is not empty
// on exit.
if (!quitting)
- hideSignal()(name, inset);
+ hideSignal->thesignal()(name, inset);
}
Dialogs::Dialogs(LyXView & lyxview)
: lyxview_(lyxview), in_show_(false)
{
+ if (!hideSignal) {
+ hideSignal = new BugfixSignal<boost::signal<void(string const
&, Inset*)> >;
+ }
// Connect signals
- connection_ = hideSignal().connect(boost::bind(&Dialogs::hideSlot,
this, _1, _2));
+ connection_ =
hideSignal->thesignal().connect(boost::bind(&Dialogs::hideSlot, this, _1, _2));
}
Dialogs::~Dialogs()
