hi!
I've successfully build kvats using gcc 4.3.1 on 64bit linux (gentoo)
aside from changing the compiler information in the top bash script a few additional changes were required:
diff -r 6b1d2205d32b libs/owutil/thread/RecursiveMutex.h
--- a/libs/owutil/thread/RecursiveMutex.h Mon Jul 07 16:51:10 2008 +0200
+++ b/libs/owutil/thread/RecursiveMutex.h Wed Jul 16 08:33:54 2008 +0200
@@ -33,13 +33,13 @@
typedef scoped_lock ScopedLock;
- void lock() {
- boost::detail::thread::lock_ops<boost::recursive_mutex>::lock(*this);
- }
-
- void unlock() {
- boost::detail::thread::lock_ops<boost::recursive_mutex>::unlock(*this);
- }
+// void lock() {
+// boost::detail::thread::lock_ops<boost::recursive_mutex>::lock(*this);
+// }
+//
+// void unlock() {
+// boost::detail::thread::lock_ops<boost::recursive_mutex>::unlock(*this);
+// }
};
diff -r 6b1d2205d32b wengophone/src/presentation/qt/chat/QtChatAvatarWidget.cpp
--- a/wengophone/src/presentation/qt/chat/QtChatAvatarWidget.cpp Mon Jul 07 16:51:10 2008 +0200
+++ b/wengophone/src/presentation/qt/chat/QtChatAvatarWidget.cpp Wed Jul 16 08:33:54 2008 +0200
@@ -51,6 +51,9 @@
defaultAvatar.loadFromData((uchar*) data.c_str(), data.size());
QPainter painter(&background);
+#ifdef HUGE
+#undef HUGE
+#endif
if (!pixmap.isNull()) {
switch (_pictureMode) {
case HUGE:
diff -r 6b1d2205d32b wifo/netlib/src/netlib.cpp
--- a/wifo/netlib/src/netlib.cpp Mon Jul 07 16:51:10 2008 +0200
+++ b/wifo/netlib/src/netlib.cpp Wed Jul 16 08:33:54 2008 +0200
@@ -39,6 +39,7 @@
#include <net/if.h>
#include <sys/ioctl.h>
#include <netdb.h>
+ #include <string.h>
#include <strings.h>
#endif //OS_WIN32
#include <stdlib.h>
this leads to successful compilation (with quite a few warnings), which also results in a working executable
placing calls and being called works quite nicely, as does messaging
sometimes, however, it insists on
putting a prefix to a sip address (43664)
furthermore it seems threads are spawned without need or limitation, usually shortly after ending a call the cpu is used by 100%, making a second call (and ending it) results in another thread consuming another 100% (on dual core) ... this continues so even a quad core will have all its cores occupied by quats (for amazing 400%)
Favoured: 0
