Assertion failed: (false), function pluginThreadEntry
yz
Assertion failed: (false), function pluginThreadEntry, file /usr/ports/
WORK/usr/ports/n
et-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 84.
Unfortunately, there's now gdb output:
Using gdb to save backtrace to /home/yz/.licq/licq.backtrace.gdb
Assertion failed: (false), function pluginThreadEntry, file /usr/ports/
WORK/usr/ports/n
et-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 84.
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-
svr4.c:1443: internal
-error: legacy_fetch_link_map_offsets called without legacy link_map
support enabled.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
Tracing with gdb (gdb /usr/local/bin/licq) shows:
(gdb) run
Starting program: /usr/local/bin/licq
[New Thread 28801140 (LWP 100234/initial thread)]
[New Thread 28850140 (LWP 100293/licq)]
[New Thread 2884fec0 (LWP 100294/licq)]
[New Thread 2884fd80 (LWP 100295/licq)]
Assertion failed: (false), function pluginThreadEntry, file /usr/ports/
WORK/usr/ports/net-im/licq/work/licq-1.5.1/src/plugins/
pluginthread.cpp, line 84.
Program received signal SIGABRT, Aborted.
[Switching to Thread 2884fd80 (LWP 100295/licq)]
0x286e64ab in thr_kill () from /lib/libc.so.7
(gdb) The program is running. Exit anyway? (y or n) y
11:24:37 [yz@yz][~]> uname -srm
FreeBSD 8.2-STABLE i386
What could cause this error and what can I do to make Licq work?
Thanx in advance for help.
Erik Johansson
On Tue, Dec 20, 2011 at 10:44, yz <yerm...@gmail.com> wrote:
> Yesterday I rebuilt my Licq 1.5.1 and it cannot start now:
> Assertion failed: (false), function pluginThreadEntry, file /usr/ports/
> WORK/usr/ports/n
> et-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 84.
It is a very strange problem. Is it possible for you to test version 1.6.0?
// Erik
--
Erik Johansson
Home Page: http://ejohansson.se/
PGP Key: http://ejohansson.se/erik.asc
George L. Yermulnik
On Tue, 20 Dec 2011 at 11:02:08 (+0100), Erik Johansson wrote:
> (Replying with the same answer as on github.)
Should we continue either on list, or at github?
> On Tue, Dec 20, 2011 at 10:44, yz <yerm...@gmail.com> wrote:
> > Yesterday I rebuilt my Licq 1.5.1 and it cannot start now:
> > Assertion failed: (false), function pluginThreadEntry, file /usr/ports/
> > WORK/usr/ports/n
> > et-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 84.
> It is a very strange problem. Is it possible for you to test version 1.6.0?
Unfortunately, there's no version 1.6.0 in FreeBSD's ports tree =( And,
probably, I won't be able to build without FreeBSD specific patches.
I've found the same problem you had participated a year ago, but there
where no thread continuation:
http://www.mail-archive.com/licq...@googlegroups.com/msg00970.html
I suspect that the problem could be caused by some library or dependency
update made recently on my sendbox. But I can't imagine which of them
exactly it is.
> // Erik
--
George L. Yermulnik
[YZ-RIPE]
Erik Johansson
> Should we continue either on list, or at github?
We can keep it here on the lit.
> Unfortunately, there's no version 1.6.0 in FreeBSD's ports tree =( And,
> probably, I won't be able to build without FreeBSD specific patches.
> I've found the same problem you had participated a year ago, but there
> where no thread continuation:
> http://www.mail-archive.com/licq...@googlegroups.com/msg00970.html
>
> I suspect that the problem could be caused by some library or dependency
> update made recently on my sendbox. But I can't imagine which of them
> exactly it is.
Can you please post the output from building licq?
Can you configure licq with -DCMAKE_BUILD_TYPE=Debug, build and see if
you get any output from gdb?
If not, can you add:
fprintf(stderr, "state=%d", data.myState);
to pluginthread.cpp just before switch (data.myState) (you may need to
add #include <stdio.h> to the top as well)
George L. Yermulnik
On Tue, 20 Dec 2011 at 11:43:39 (+0100), Erik Johansson wrote:
> > Unfortunately, there's no version 1.6.0 in FreeBSD's ports tree =( And,
> > probably, I won't be able to build without FreeBSD specific patches.
> > I've found the same problem you had participated a year ago, but there
> > where no thread continuation:
> > http://www.mail-archive.com/licq...@googlegroups.com/msg00970.html
> > I suspect that the problem could be caused by some library or dependency
> > update made recently on my sendbox. But I can't imagine which of them
> > exactly it is.
> Can you please post the output from building licq?
attached: portupgrade.net-im::licq.log
> Can you configure licq with -DCMAKE_BUILD_TYPE=Debug, build and see if
> you get any output from gdb?
Guess, something wrong is with my GDB:
--- cut ---
#> licq
Assertion failed: (false), function pluginThreadEntry, file /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 84.
Using gdb to save backtrace to /home/yz/.licq/licq.backtrace.gdb
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled.
A problem internal to GDB has been detected,
--- cut ---
/home/yz/.licq/licq.backtrace.gdb is empty
> If not, can you add:
> fprintf(stderr, "state=%d", data.myState);
> to pluginthread.cpp just before switch (data.myState) (you may need to
> add #include <stdio.h> to the top as well)
state=2
state=3
state=2
state=3
state=2
state=3
state=1
Assertion failed: (false), function pluginThreadEntry, file /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 85.
Using gdb to save backtrace to /home/yz/.licq/licq.backtrace.gdb
state=1
Assertion failed: (false), function pluginThreadEntry, file /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 85.
Anders Olofsson
> Hello!
>
> On Tue, 20 Dec 2011 at 11:43:39 (+0100), Erik Johansson wrote:
>
>>> Unfortunately, there's no version 1.6.0 in FreeBSD's ports tree =( And,
>>> probably, I won't be able to build without FreeBSD specific patches.
Assuming I found the correct link, it's not that big patches so you
should be able to try.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/net-im/licq/files/
>>> I've found the same problem you had participated a year ago, but there
>>> where no thread continuation:
>>> http://www.mail-archive.com/licq...@googlegroups.com/msg00970.html
The backtrace there definitely looks consistent with what you're getting
here. Unfortunately I can't see any answer in it to why it is happening.
I want to see what belongs to which plugin here. Please run it again but
with "licq -d15" to make it print the plugin names as they are initiated
and started.
/Anders
Erik Johansson
> state=2
> state=3
> state=2
> state=3
> state=2
> state=3
> state=1
> Assertion failed: (false), function pluginThreadEntry, file /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 85.
After googling a bit I realize that my assumption that
pthread_cond_wait() only returns due to a call to
pthread_cond_signal() or pthread_cond_broadcast() is wrong. According
to http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/034573.html
pthread_cond_wait() can return for no apparent reason.
Please try the patch below and see if it fixes the problem for you:
diff --git a/licq/src/plugins/pluginthread.cpp
b/licq/src/plugins/pluginthread.cpp
index 0a4f249..90d8a7c 100644
--- a/licq/src/plugins/pluginthread.cpp
+++ b/licq/src/plugins/pluginthread.cpp
@@ -73,7 +73,10 @@ static void* pluginThreadEntry(void* arg)
while (data.myState == PluginThread::Data::STATE_WAITING)
{
- data.myCondition.wait(data.myMutex);
+ do
+ {
+ data.myCondition.wait(data.myMutex);
+ } while (data.myState == PluginThread::Data::STATE_WAITING);
switch (data.myState)
{
George L. Yermulnik
On Tue, 20 Dec 2011 at 19:46:51 (+0100), Erik Johansson wrote:
> On Tue, Dec 20, 2011 at 12:45, George L. Yermulnik <yerm...@gmail.com> wrote:
> > state=2
> > state=3
> > state=2
> > state=3
> > state=2
> > state=3
> > state=1
> > Assertion failed: (false), function pluginThreadEntry, file /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 85.
> After googling a bit I realize that my assumption that
> pthread_cond_wait() only returns due to a call to
> pthread_cond_signal() or pthread_cond_broadcast() is wrong. According
> to http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/034573.html
> pthread_cond_wait() can return for no apparent reason.
> Please try the patch below and see if it fixes the problem for you:
Yep! This helps!
Thanx a lot for your help!!! =)
If it's not too bad-mannered, I'd like to ask you to take a look at
another issue I have here on my sendbox. It's not a fault or something
like that, but is very annoying: after upgrading from 1.3.x to 1.5.x
each time I open the main contact list window from a systray it goes up
vertically for exactly half a centimeter. Maybe it's not because of any
Licq components. So I'm just asking for your opinion =)
And a feature request =) Is it possible to add possibility to toggle
main contact list window state (open/close) via licq_fifo?
ps: thank you one more time for your work! =)
> diff --git a/licq/src/plugins/pluginthread.cpp
> b/licq/src/plugins/pluginthread.cpp
> index 0a4f249..90d8a7c 100644
> --- a/licq/src/plugins/pluginthread.cpp
> +++ b/licq/src/plugins/pluginthread.cpp
> @@ -73,7 +73,10 @@ static void* pluginThreadEntry(void* arg)
> while (data.myState == PluginThread::Data::STATE_WAITING)
> {
> - data.myCondition.wait(data.myMutex);
> + do
> + {
> + data.myCondition.wait(data.myMutex);
> + } while (data.myState == PluginThread::Data::STATE_WAITING);
> switch (data.myState)
> {
> // Erik
--
George L. Yermulnik
[YZ-RIPE]
George L. Yermulnik
On Tue, 20 Dec 2011 at 19:46:13 (+0100), Anders Olofsson wrote:
> >>> Unfortunately, there's no version 1.6.0 in FreeBSD's ports tree =( And,
> >>> probably, I won't be able to build without FreeBSD specific patches.
> Assuming I found the correct link, it's not that big patches so you
> should be able to try.
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/net-im/licq/files/
I've tried Erik's patch and it helped.
> >> If not, can you add:
> >> fprintf(stderr, "state=%d", data.myState);
> >> to pluginthread.cpp just before switch (data.myState) (you may need to
> >> add #include<stdio.h> to the top as well)
> > state=2
> > state=3
> > state=2
> > state=3
> > state=2
> > state=3
> > state=1
> > Assertion failed: (false), function pluginThreadEntry, file /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 85.
> I want to see what belongs to which plugin here. Please run it again but
> with "licq -d15" to make it print the plugin names as they are initiated
> and started.
If it's necessary for you to improve Licq development, I can revert
Erik's patch and try to make this "debugging". Notify me if it's needed.
> /Anders
Anders Olofsson
> If it's not too bad-mannered, I'd like to ask you to take a look at
> another issue I have here on my sendbox. It's not a fault or something
> like that, but is very annoying: after upgrading from 1.3.x to 1.5.x
> each time I open the main contact list window from a systray it goes up
> vertically for exactly half a centimeter. Maybe it's not because of any
> Licq components. So I'm just asking for your opinion =)
Did you use Qt4-Gui with 1.3.x so you can tell if the problem appeared
with the new Licq version and not the switch to Qt4?
Which window manager are you using?
Does it happen if you just minimize and restore it normally to the taskbar?
> And a feature request =) Is it possible to add possibility to toggle
> main contact list window state (open/close) via licq_fifo?
That should be possible. I'll have a look at it and see what I can do.
/Anders
George L. Yermulnik
On Wed, 21 Dec 2011 at 19:37:29 (+0100), Anders Olofsson wrote:
> > If it's not too bad-mannered, I'd like to ask you to take a look at
> > another issue I have here on my sendbox. It's not a fault or something
> > like that, but is very annoying: after upgrading from 1.3.x to 1.5.x
> > each time I open the main contact list window from a systray it goes up
> > vertically for exactly half a centimeter. Maybe it's not because of any
> > Licq components. So I'm just asking for your opinion =)
> Did you use Qt4-Gui with 1.3.x so you can tell if the problem appeared
> with the new Licq version and not the switch to Qt4?
I can't recall which Qt version I had been using before upgrading to
1.5.x =( That happened along with installing my new workstation from
scratch. But I surely remember that this behaviour appeared exactly
after upgrading to 1.5.0.
> Which window manager are you using?
Enlightenment (E16) 1.0.10
> Does it happen if you just minimize and restore it normally to the taskbar?
Nope, it doesn't. It happens only when left-clicking on Licq tray icon
to show/hide main window.
I've noticed another "side effect": with main window opened first tray
icon click sets window to sticky state and only the second click hides
the window.
Log message is:
<timestamp> [INF] qt4 gui: Setting Sticky state of window 0x28000ca to true
It's not that critical and I almost got used to this behavior. So If I'm
the only one reporting such a "bug", guess it doesn't worth your
attention as it might be because of some misconfiguration of my WM or
anything like that =)
> > And a feature request =) Is it possible to add possibility to toggle
> > main contact list window state (open/close) via licq_fifo?
> That should be possible. I'll have a look at it and see what I can do.
Thanx a lot =)
And one more "feature" request =)
Can you please add "//IGNORE" for `tocode' of iconv_open() in src/licq-osd.cpp ?
It should make iconv silently discard unconvertable chars instead of
failing itself at all.
> /Anders
George L. Yermulnik
> Enlightenment (E16) 1.0.10
> Thanx a lot =)
I catched some kind of "crash" with my mailbox, so I'd like to ask if I
missed your answer or there were no answer yet? =)
Anders Olofsson
> Hello!
>
> On Thu, 22 Dec 2011 at 11:49:58 (+0200), George L. Yermulnik wrote:
>
>>>> If it's not too bad-mannered, I'd like to ask you to take a look at
>>>> another issue I have here on my sendbox. It's not a fault or something
>>>> like that, but is very annoying: after upgrading from 1.3.x to 1.5.x
>>>> each time I open the main contact list window from a systray it goes up
>>>> vertically for exactly half a centimeter. Maybe it's not because of any
>>>> Licq components. So I'm just asking for your opinion =)
>
>>> Did you use Qt4-Gui with 1.3.x so you can tell if the problem appeared
>>> with the new Licq version and not the switch to Qt4?
>
>> I can't recall which Qt version I had been using before upgrading to
>> 1.5.x =( That happened along with installing my new workstation from
>> scratch. But I surely remember that this behaviour appeared exactly
>> after upgrading to 1.5.0.
>
>>> Which window manager are you using?
>
>> Enlightenment (E16) 1.0.10
Never used it. I'll install it and see if I get the same behavior.
>>> Does it happen if you just minimize and restore it normally to the taskbar?
>
>> Nope, it doesn't. It happens only when left-clicking on Licq tray icon
>> to show/hide main window.
>> I've noticed another "side effect": with main window opened first tray
>> icon click sets window to sticky state and only the second click hides
>> the window.
>> Log message is:
>> <timestamp> [INF] qt4 gui: Setting Sticky state of window 0x28000ca to true
>
>> It's not that critical and I almost got used to this behavior. So If I'm
>> the only one reporting such a "bug", guess it doesn't worth your
>> attention as it might be because of some misconfiguration of my WM or
>> anything like that =)
The logic when clicking the system tray is to hide the main window only
if it is already the active window. So if the main window is visible,
but not active, it will only be raised. The sticky flag is always set
when showing regardless if the window was hidden before.
Do you need to click twice even when the main window already is in focus
or is there something else in focus when you see this behavior?
If you disable the "Sticky main window" setting, does the main window
still get placed too high?
>>>> And a feature request =) Is it possible to add possibility to toggle
>>>> main contact list window state (open/close) via licq_fifo?
I've added fifo commands "ui_showuserlist" and "ui_hideuserlist" as new
features for future Licq 1.7.0.
>> And one more "feature" request =)
>> Can you please add "//IGNORE" for `tocode' of iconv_open() in src/licq-osd.cpp ?
>> It should make iconv silently discard unconvertable chars instead of
>> failing itself at all.
Fixed, also for 1.7.0.
> I catched some kind of "crash" with my mailbox, so I'd like to ask if I
> missed your answer or there were no answer yet? =)
No, you didn't miss anything. I was away during christmas and just
forgot this thread so it's a good thing you reminded me.
/Anders
George L. Yermulnik
On Thu, 29 Dec 2011 at 14:19:27 (+0100), Anders Olofsson wrote:
> >>>> If it's not too bad-mannered, I'd like to ask you to take a look at
> >>>> another issue I have here on my sendbox. It's not a fault or something
> >>>> like that, but is very annoying: after upgrading from 1.3.x to 1.5.x
> >>>> each time I open the main contact list window from a systray it goes up
> >>>> vertically for exactly half a centimeter. Maybe it's not because of any
> >>>> Licq components. So I'm just asking for your opinion =)
> >>> Did you use Qt4-Gui with 1.3.x so you can tell if the problem appeared
> >>> with the new Licq version and not the switch to Qt4?
> >> I can't recall which Qt version I had been using before upgrading to
> >> 1.5.x =( That happened along with installing my new workstation from
> >> scratch. But I surely remember that this behaviour appeared exactly
> >> after upgrading to 1.5.0.
> >>> Which window manager are you using?
> >> Enlightenment (E16) 1.0.10
> Never used it. I'll install it and see if I get the same behavior.
Ok, thanx a lot.
> >>> Does it happen if you just minimize and restore it normally to the taskbar?
> >> Nope, it doesn't. It happens only when left-clicking on Licq tray icon
> >> to show/hide main window.
> >> I've noticed another "side effect": with main window opened first tray
> >> icon click sets window to sticky state and only the second click hides
> >> the window.
> >> Log message is:
> >> <timestamp> [INF] qt4 gui: Setting Sticky state of window 0x28000ca to true
> >> It's not that critical and I almost got used to this behavior. So If I'm
> >> the only one reporting such a "bug", guess it doesn't worth your
> >> attention as it might be because of some misconfiguration of my WM or
> >> anything like that =)
> The logic when clicking the system tray is to hide the main window only
> if it is already the active window. So if the main window is visible,
> but not active, it will only be raised. The sticky flag is always set
> when showing regardless if the window was hidden before.
Oh, I see. Then everything is ok and works as it is supposed to =)
> Do you need to click twice even when the main window already is in focus
> or is there something else in focus when you see this behavior?
Everything works as you described above: first click focuses the window
and second one hides the window. Only one click needed if the main
window already has focus. Is it a new behavior in 1.5.x? I can't
remember that in 1.3.x. So that made me think this is some kind of "bug"
=)
> If you disable the "Sticky main window" setting, does the main window
> still get placed too high?
Yes, it does =(
> >>>> And a feature request =) Is it possible to add possibility to toggle
> >>>> main contact list window state (open/close) via licq_fifo?
> I've added fifo commands "ui_showuserlist" and "ui_hideuserlist" as new
> features for future Licq 1.7.0.
Thanx! =)
May I ask you for a diff to try it with my 1.5.1?
> >> And one more "feature" request =)
> >> Can you please add "//IGNORE" for `tocode' of iconv_open() in src/licq-osd.cpp ?
> >> It should make iconv silently discard unconvertable chars instead of
> >> failing itself at all.
> Fixed, also for 1.7.0.
Thank you very much =)
> > I catched some kind of "crash" with my mailbox, so I'd like to ask if I
> > missed your answer or there were no answer yet? =)
> No, you didn't miss anything. I was away during christmas and just
> forgot this thread so it's a good thing you reminded me.
=)
Happy New Year and Marry Christmas =) And thank you one more time for
your help =)
Anders Olofsson
> Hello!
>
> On Thu, 29 Dec 2011 at 14:19:27 (+0100), Anders Olofsson wrote:
>
>>>>>> If it's not too bad-mannered, I'd like to ask you to take a look at
>>>>>> another issue I have here on my sendbox. It's not a fault or something
>>>>>> like that, but is very annoying: after upgrading from 1.3.x to 1.5.x
>>>>>> each time I open the main contact list window from a systray it goes up
>>>>>> vertically for exactly half a centimeter. Maybe it's not because of any
>>>>>> Licq components. So I'm just asking for your opinion =)
>
>>>>> Did you use Qt4-Gui with 1.3.x so you can tell if the problem appeared
>>>>> with the new Licq version and not the switch to Qt4?
>
>>>> I can't recall which Qt version I had been using before upgrading to
>>>> 1.5.x =( That happened along with installing my new workstation from
>>>> scratch. But I surely remember that this behaviour appeared exactly
>>>> after upgrading to 1.5.0.
>
>>>>> Which window manager are you using?
>
>>>> Enlightenment (E16) 1.0.10
>
>> Never used it. I'll install it and see if I get the same behavior.
>
> Ok, thanx a lot.
I've tried it and I see the same behavior. However after some searching
I found that it's a problem in Enlightenment, not Licq. I found a bug
for it already reported:
http://trac.enlightenment.org/e/ticket/519
It might be possible to make some kind of workaround in Licq, but it
wouldn't be pretty so I'd prefer not to.
>>>>>> And a feature request =) Is it possible to add possibility to toggle
>>>>>> main contact list window state (open/close) via licq_fifo?
>
>> I've added fifo commands "ui_showuserlist" and "ui_hideuserlist" as new
>> features for future Licq 1.7.0.
>
> Thanx! =)
> May I ask you for a diff to try it with my 1.5.1?
The following three commits add the fifo changes but I can't guarantee
that this will apply cleanly on 1.5.1.
http://github.com/licq-im/licq/commit/ab59e4c10ff4fd1baece06baba19b402561e5af5
http://github.com/licq-im/licq/commit/5a2bd4da786e1bdf28c8da8bfddb501e87f10268
http://github.com/licq-im/licq/commit/3738106b6631c973fd1d8129f164fdf9cb0ebbdd
/Anders
George L. Yermulnik
On Sun, 01 Jan 2012 at 20:14:14 (+0100), Anders Olofsson wrote:
> >>>>>> And a feature request =) Is it possible to add possibility to toggle
> >>>>>> main contact list window state (open/close) via licq_fifo?
> >> I've added fifo commands "ui_showuserlist" and "ui_hideuserlist" as new
> >> features for future Licq 1.7.0.
> > Thanx! =)
> > May I ask you for a diff to try it with my 1.5.1?
> The following three commits add the fifo changes but I can't guarantee
> that this will apply cleanly on 1.5.1.
Thanx a lot. I'll try to apply them to 1.5.1 later.
One more question: is it possible to make single signal to show/hide -
show if it's hidden and hide if it's shown? It's much more convenient to
have a single keyboard shortcut to show/hide instead of two ones.
> http://github.com/licq-im/licq/commit/ab59e4c10ff4fd1baece06baba19b402561e5af5
> http://github.com/licq-im/licq/commit/5a2bd4da786e1bdf28c8da8bfddb501e87f10268
> http://github.com/licq-im/licq/commit/3738106b6631c973fd1d8129f164fdf9cb0ebbdd
> /Anders
--
George L. Yermulnik
[YZ-RIPE]
Anders Olofsson
> Hello!
>
> show if it's hidden and hide if it's shown? It's much more convenient to
> have a single keyboard shortcut to show/hide instead of two ones.
If it's just a keyboard shortcut, there already is a configurable hot
key in the gui. Currently it will just show the main window, but I could
modify it to hide the window if it's already active, just like the dock
icon does.
Or is there a specific reason you want to use the fifo instead of having
the shortcut directly in the gui?
/Anders
George L. Yermulnik
On Tue, 10 Jan 2012 at 19:25:32 (+0100), Anders Olofsson wrote:
> > One more question: is it possible to make single signal to show/hide -
> > show if it's hidden and hide if it's shown? It's much more convenient to
> > have a single keyboard shortcut to show/hide instead of two ones.
> If it's just a keyboard shortcut, there already is a configurable hot
> key in the gui. Currently it will just show the main window, but I could
> modify it to hide the window if it's already active, just like the dock
> icon does.
That would be great!
> Or is there a specific reason you want to use the fifo instead of having
> the shortcut directly in the gui?
No, it's just a habit: I use fifo commands to view events and to write
messages to some specific contacts. Say, the main reason is keeping all
of the shortcuts in the same "origin" (fifo). But I don't really care if
it's fifo or hotkey in the gui config =) Thanx for reminding about gui
option =) It would be really great if it will work as a "toggle" hotkey
like a dock icon does.
Anders Olofsson
> Hello!
>
> On Tue, 10 Jan 2012 at 19:25:32 (+0100), Anders Olofsson wrote:
>
>>> One more question: is it possible to make single signal to show/hide -
>>> show if it's hidden and hide if it's shown? It's much more convenient to
>>> have a single keyboard shortcut to show/hide instead of two ones.
>
>> If it's just a keyboard shortcut, there already is a configurable hot
>> key in the gui. Currently it will just show the main window, but I could
>> modify it to hide the window if it's already active, just like the dock
>> icon does.
>
> That would be great!
After opening the code I see that it already works this way. However the
hotkey for the main window was added in Licq 1.6.0 so I guess you now
have another reason to upgrade.
/Anders
George L. Yermulnik
On Tue, 10 Jan 2012 at 22:03:21 (+0100), Anders Olofsson wrote:
> >>> One more question: is it possible to make single signal to show/hide -
> >>> show if it's hidden and hide if it's shown? It's much more convenient to
> >>> have a single keyboard shortcut to show/hide instead of two ones.
> >> If it's just a keyboard shortcut, there already is a configurable hot
> >> key in the gui. Currently it will just show the main window, but I could
> >> modify it to hide the window if it's already active, just like the dock
> >> icon does.
> > That would be great!
> After opening the code I see that it already works this way. However the
> hotkey for the main window was added in Licq 1.6.0 so I guess you now
> have another reason to upgrade.
Ok, I see... Well, will try to upgrade. Thanx a lot for your help =)
George L. Yermulnik
On Tue, 10 Jan 2012 at 22:03:21 (+0100), Anders Olofsson wrote:
> After opening the code I see that it already works this way. However the
> hotkey for the main window was added in Licq 1.6.0 so I guess you now
> have another reason to upgrade.
Trying to build Licq 1.6.0, but got no success =(
Using GCC 4.2 from base system (FreeBSD 8.2):
--- cut ---
[skipped]
[ 6%] Building CXX object src/CMakeFiles/licq.dir/daemon.cpp.o
In file included from /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:22:
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.h:90: error: cannot declare variable 'LicqDaemon::gDaemon' to be of abstract type 'LicqDaemon::Daemon'
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.h:33: note: because the following virtual functions are pure within 'LicqDaemon::Daemon':
/usr/local/include/licq/daemon.h:66: note: virtual Licq::LogService& Licq::Daemon::getLogService()
In file included from /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:48:
/usr/ports/net-im/licq/work/licq-1.6.0/src/contactlist/usermanager.h:186: error: cannot declare variable 'LicqDaemon::gUserManager' to be of abstract type 'LicqDaemon::UserManager'
/usr/ports/net-im/licq/work/licq-1.6.0/src/contactlist/usermanager.h:42: note: because the following virtual functions are pure within 'LicqDaemon::UserManager':
/usr/local/include/licq/contactlist/usermanager.h:234: note: virtual void Licq::UserManager::userStatusChanged(const Licq::UserId&, unsigned int)
/usr/local/include/licq/contactlist/usermanager.h:243: note: virtual void Licq::UserManager::ownerStatusChanged(long unsigned int, unsigned int)
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:66: error: cannot declare variable 'LicqDaemon::gDaemon' to be of abstract type 'LicqDaemon::Daemon'
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.h:33: note: since type 'LicqDaemon::Daemon' has pure virtual functions
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp: In member function 'void LicqDaemon::Daemon::initialize()':
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:120: error: 'ProxyTypeHttp' was not declared in this scope
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:143: error: 'gLogService' is not a member of 'Licq'
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp: In member function 'virtual void LicqDaemon::Daemon::SaveConf()':
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:241: error: 'class Licq::Owner' has no member named 'save'
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:241: error: 'SaveOwnerInfo' is not a member of 'Licq::User'
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:245: error: 'protocolId_toString' is not a member of 'Licq'
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp: In member function 'Licq::Proxy* Licq::Daemon::createProxy()':
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:341: error: 'ProxyTypeHttp' was not declared in this scope
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp: In member function 'virtual bool LicqDaemon::Daemon::addUserEvent(Licq::User*, Licq::UserEvent*)':
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:392: error: 'class Licq::UserEvent' has no member named 'eventType'
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:392: error: 'TypeEmailPager' is not a member of 'Licq::UserEvent'
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:393: error: 'class Licq::UserEvent' has no member named 'eventType'
/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:393: error: 'TypeWebPanel' is not a member of 'Licq::UserEvent'
*** Error code 1
--- cut ---
Using GCC 4.4 from ports collection (FreeBSD 8.2):
--- cut ---
[skipped]
Linking CXX executable unittest
[ 95%] Built target unittest
Scanning dependencies of target unittest_run
[ 95%] Running unit test
Test project /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.6.0/src
Start 1: licq
1/1 Test #1: licq .............................***Failed 0.00 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 0.00 sec
The following tests FAILED:
1 - licq (Failed)
Errors while running CTest
*** Error code 8
--- cut ---
Problem with running Licq built using non-default GCC (not from base
system) exists for a long time and, I guess, is related to some libs
from base system built with GCC from base system.
Licq 1.5.1 builds and runs fine with GCC 4.2 from my base system. But
1.6.0 - does not. Have you got any ideas what should I do to "fight
down" this? =)
Erik Johansson
> [ 6%] Building CXX object src/CMakeFiles/licq.dir/daemon.cpp.o
> In file included from /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:22:
> /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.h:90: error: cannot declare variable 'LicqDaemon::gDaemon' to be of abstract type 'LicqDaemon::Daemon'
> /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.h:33: note: because the following virtual functions are pure within 'LicqDaemon::Daemon':
> /usr/local/include/licq/daemon.h:66: note: virtual Licq::LogService& Licq::Daemon::getLogService()
For some reason licq is being built using the installed headers which
I assume are from 1.5.1. It should use the headers from the source.
Could you post the output from running cmake and from running make VERBOSE=1?
George L. Yermulnik
On Fri, 13 Jan 2012 at 13:11:46 (+0100), Erik Johansson wrote:
> On Fri, Jan 13, 2012 at 11:43, George L. Yermulnik <yerm...@gmail.com> wrote:
> > [ О©╫6%] Building CXX object src/CMakeFiles/licq.dir/daemon.cpp.o
> > In file included from /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp:22:
> > /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.h:90: error: cannot declare variable 'LicqDaemon::gDaemon' to be of abstract type 'LicqDaemon::Daemon'
> > /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.h:33: note: О©╫ because the following virtual functions are pure within 'LicqDaemon::Daemon':
> > /usr/local/include/licq/daemon.h:66: note: О©╫ О©╫ О©╫virtual Licq::LogService& Licq::Daemon::getLogService()
> For some reason licq is being built using the installed headers which
> I assume are from 1.5.1. It should use the headers from the source.
> Could you post the output from running cmake
I'm not common with `cmake' and doing `cmake' in the directory, where
ports collection extracts Licq sources, just gives me the help message:
14:29:55 [root#yz][.../work/licq-1.6.0]> cmake
cmake version 2.8.3
Usage
cmake [options] <path-to-source>
cmake [options] <path-to-existing-build>
[skipped]
> and from running make VERBOSE=1?
[root#yz][/usr/ports/net-im/licq]> make VERBOSE=1
[skipped]
/usr/local/bin/cmake -E cmake_progress_report /usr/ports/net-im/licq/work/licq-1.6.0/CMakeFiles 6
[ 6%] Building CXX object src/CMakeFiles/licq.dir/daemon.cpp.o
cd /usr/ports/net-im/licq/work/licq-1.6.0/src && /usr/bin/c++ -D_REENTRANT -O2 -pipe -I/usr/local/include -fno-strict-aliasing -Wl,--export-dynamic -O2 -pipe -I/usr/local/include -fno-strict-aliasing -Wl,--export-dynamic -DLICQDAEMON_DEBUG_RW_MUTEX=1 -I/usr/ports/net-im/licq/work/licq-1.6.0/include -I/usr/local/include -I/usr/ports/net-im/licq/work/licq-1.6.0/src -I/usr/local/include/gpgme -I/usr/ports/net-im/licq/work/licq-1.6.0/3rdparty/gtest/include -I/usr/ports/net-im/licq/work/licq-1.6.0/3rdparty/gmock/include -Wall -Wextra -o CMakeFiles/licq.dir/daemon.cpp.o -c /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp
following by errors mentioned in my previous email.
Erik Johansson
> On Fri, 13 Jan 2012 at 13:11:46 (+0100), Erik Johansson wrote:
>> Could you post the output from running cmake
>
> I'm not common with `cmake' and doing `cmake' in the directory, where
> ports collection extracts Licq sources, just gives me the help message:
Could you please post the files CMakeCache.txt,
CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log? They should
be in the build directory.
> cd /usr/ports/net-im/licq/work/licq-1.6.0/src && /usr/bin/c++ -D_REENTRANT -O2 -pipe -I/usr/local/include -fno-strict-aliasing -Wl,--export-dynamic -O2 -pipe -I/usr/local/include -fno-strict-aliasing -Wl,--export-dynamic -DLICQDAEMON_DEBUG_RW_MUTEX=1 -I/usr/ports/net-im/licq/work/licq-1.6.0/include -I/usr/local/include -I/usr/ports/net-im/licq/work/licq-1.6.0/src -I/usr/local/include/gpgme -I/usr/ports/net-im/licq/work/licq-1.6.0/3rdparty/gtest/include -I/usr/ports/net-im/licq/work/licq-1.6.0/3rdparty/gmock/include -Wall -Wextra -o CMakeFiles/licq.dir/daemon.cpp.o -c /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp
-I/usr/local/include appears before
-I/usr/ports/net-im/licq/work/licq-1.6.0/include which causes the
problem. A quick fix is to (re)move /usr/local/include/licq before
building (or uninstall the old version). Not a real fix, but it should
give you a working licq while we try to figure out a real fix.
George L. Yermulnik
On Fri, 13 Jan 2012 at 14:18:43 (+0100), Erik Johansson wrote:
> Could you please post the files CMakeCache.txt,
> CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log? They should
> be in the build directory.
attached.
> > cd /usr/ports/net-im/licq/work/licq-1.6.0/src && /usr/bin/c++ О©╫ -D_REENTRANT -O2 -pipe -I/usr/local/include -fno-strict-aliasing -Wl,--export-dynamic -O2 -pipe -I/usr/local/include -fno-strict-aliasing -Wl,--export-dynamic -DLICQDAEMON_DEBUG_RW_MUTEX=1 -I/usr/ports/net-im/licq/work/licq-1.6.0/include -I/usr/local/include -I/usr/ports/net-im/licq/work/licq-1.6.0/src -I/usr/local/include/gpgme -I/usr/ports/net-im/licq/work/licq-1.6.0/3rdparty/gtest/include -I/usr/ports/net-im/licq/work/licq-1.6.0/3rdparty/gmock/include О©╫ -Wall -Wextra -o CMakeFiles/licq.dir/daemon.cpp.o -c /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp
> -I/usr/local/include appears before
> -I/usr/ports/net-im/licq/work/licq-1.6.0/include which causes the
> problem. A quick fix is to (re)move /usr/local/include/licq before
> building (or uninstall the old version). Not a real fix, but it should
> give you a working licq while we try to figure out a real fix.
Ok, I'll try to move /usr/local/include/licq
> // Erik
George L. Yermulnik
On Fri, 13 Jan 2012 at 14:18:43 (+0100), Erik Johansson wrote:
> -I/usr/local/include appears before
> -I/usr/ports/net-im/licq/work/licq-1.6.0/include which causes the
> problem. A quick fix is to (re)move /usr/local/include/licq before
> building (or uninstall the old version). Not a real fix, but it should
> give you a working licq while we try to figure out a real fix.
It helped. Going to try to install =)
> // Erik
Erik Johansson
>
>> -I/usr/local/include appears before
>> -I/usr/ports/net-im/licq/work/licq-1.6.0/include which causes the
>> problem.
I think that the problem might be in the ports' Makefile. Can you
please comment out the CPPFLAGS+= and CFLAGS+= lines in the Makefile
[1] and build with VERBOSE=1 and post the output when daemon.cpp is
built.
// Erik
[1] - http://www.freebsd.org/cgi/cvsweb.cgi/ports/net-im/licq/Makefile?rev=1.80
George L. Yermulnik
On Sat, 14 Jan 2012 at 09:52:12 (+0100), Erik Johansson wrote:
> 2012/1/13 George L. Yermulnik <yerm...@gmail.com>:
> > On Fri, 13 Jan 2012 at 14:18:43 (+0100), Erik Johansson wrote:
> >> > cd /usr/ports/net-im/licq/work/licq-1.6.0/src && /usr/bin/c++ О©╫ -D_REENTRANT -O2 -pipe -I/usr/local/include -fno-strict-aliasing -Wl,--export-dynamic -O2 -pipe -I/usr/local/include -fno-strict-aliasing -Wl,--export-dynamic -DLICQDAEMON_DEBUG_RW_MUTEX=1 -I/usr/ports/net-im/licq/work/licq-1.6.0/include -I/usr/local/include -I/usr/ports/net-im/licq/work/licq-1.6.0/src -I/usr/local/include/gpgme -I/usr/ports/net-im/licq/work/licq-1.6.0/3rdparty/gtest/include -I/usr/ports/net-im/licq/work/licq-1.6.0/3rdparty/gmock/include О©╫ -Wall -Wextra -o CMakeFiles/licq.dir/daemon.cpp.o -c /usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp
> >> -I/usr/local/include appears before
> >> -I/usr/ports/net-im/licq/work/licq-1.6.0/include which causes the
> >> problem.
> I think that the problem might be in the ports' Makefile. Can you
> please comment out the CPPFLAGS+= and CFLAGS+= lines in the Makefile
> [1] and build with VERBOSE=1 and post the output when daemon.cpp is
> built.
I've already upgraded to 1.6.0. Before upgrading I moved
/usr/local/include/licq/ to another location as you suggested and it
worked fine. So I can't build with includes from Licq 1.5.x being in
includes path, but I have just done it with commented out
CPPFLAGS/CFLAGS and it worked fine for 1.6.0 (/usr/local/include/licq/
was moved to another location).
Should I point that to Licq port maintainer and ask him to comment out
CPPFLAGS/CFLAGS definitions as they lead to such a race condition?
--- cut ---
/usr/local/bin/cmake -E cmake_progress_report /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.6.0/CMakeFiles 6
[ 6%] Building CXX object src/CMakeFiles/licq.dir/daemon.cpp.o
cd /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.6.0/src && /usr/bin/c++ -D_REENTRANT -O2 -pipe -fno-strict-aliasing -Wl,--export-dynamic -O2 -pipe -fno-strict-aliasing -Wl,--export-dynamic -DLICQDAEMON_DEBUG_RW_MUTEX=1 -I/usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.6.0/include -I/usr/local/include -I/usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.6.0/src -I/usr/local/include/gpgme -I/usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.6.0/3rdparty/gtest/include -I/usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.6.0/3rdparty/gmock/include -Wall -Wextra -o CMakeFiles/licq.dir/daemon.cpp.o -c /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.6.0/src/daemon.cpp
c++: --export-dynamic: linker input file unused because linking not done
c++: --export-dynamic: linker input file unused because linking not done
--- cut ---
> // Erik
> [1] - http://www.freebsd.org/cgi/cvsweb.cgi/ports/net-im/licq/Makefile?rev=1.80
--
George L. Yermulnik
[YZ-RIPE]
Erik Johansson
> So I can't build with includes from Licq 1.5.x being in
> includes path, but I have just done it with commented out
> CPPFLAGS/CFLAGS and it worked fine for 1.6.0 (/usr/local/include/licq/
> was moved to another location).
>
> Should I point that to Licq port maintainer and ask him to comment out
> CPPFLAGS/CFLAGS definitions as they lead to such a race condition?
Yes, please do. Removing those lines seems like the correct solution.
// Erik
George L. Yermulnik
On Mon, 16 Jan 2012 at 16:06:34 (+0100), Erik Johansson wrote:
> 2012/1/16 George L. Yermulnik <yerm...@gmail.com>:
> > So I can't build with includes from Licq 1.5.x being in
> > includes path, but I have just done it with commented out
> > CPPFLAGS/CFLAGS and it worked fine for 1.6.0 (/usr/local/include/licq/
> > was moved to another location).
> > Should I point that to Licq port maintainer and ask him to comment out
> > CPPFLAGS/CFLAGS definitions as they lead to such a race condition?
> Yes, please do. Removing those lines seems like the correct solution.
Ok. I'll do that today.
Thanx for helping =)
> // Erik