[Ekiga-devel-list] WIN32?
Folks! - What's the status of the WIN32 installer? - Which version is the current GTK+ port? J. -- I know life sometimes can get tough! and I know life sometimes can be a drag! But people, we have been given a gift, we have been given a road And that roads name is... rock and roll! KISS in "God gave Rock'n'Roll to you" ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] win32 build
Hi, I would like to write a Nullsoft Scriptable Install for ekiga on windows. But I try to cross-compile with the script on the snapshots site but it doesn't work. It seems there is too much change since these script. Is there anybody who have an updated build script for win32. Thanks Cédric Krier pgpuLfRVau3kt.pgp Description: PGP signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] win32 build
Hi all, about the windows port of ekiga I have some questions, I would like to set up a build environment.I am aware that I need ptlib_win32, opal and of course ekiga. Do I need anything else installed except for minGW and MSYS? starting with ptlib I found the problem that although I may run configure.exe I do not get a makefile.. It would be very nice if someone could give me some hints.. Also I would like to know know more about the state of the current windows port (talking about svn head) Thank you in advance, Matthias This message was sent using IMP, the Internet Messaging Program. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 Compile
Hi, I am new to Ekiga and I am looking for more of a step-by-step info on how to compile Ekiga in Windows XP environment. I have tried to use the ekiga_build scripts and I had no success. I did a make on the cygwin command prompt and it gave me these: $ make make: dpkg-architecture: Command not found Checking prerequisites... /bin/sh: line 0: hash: i586-mingw32msvc-gcc: not found /bin/sh: line 0: hash: i586-mingw32msvc-g++: not found /bin/sh: line 0: hash: i586-mingw32msvc-ld: not found /bin/sh: line 0: hash: i586-mingw32msvc-nm: not found /bin/sh: line 0: hash: i586-mingw32msvc-ar: not found /bin/sh: line 0: hash: i586-mingw32msvc-ranlib: not found /bin/sh: line 0: hash: i586-mingw32msvc-dlltool: not found /bin/sh: line 0: hash: i586-mingw32msvc-dllwrap: not found /bin/sh: line 0: hash: i586-mingw32msvc-objdump: not found /bin/sh: line 0: hash: i586-mingw32msvc-windres: not found /bin/sh: line 0: hash: i586-mingw32msvc-as: not found You need to install mingw32 make: *** [binaries] Error 1 I had MingGW-5.1.3 installed but I can't find the above stuff. Please help. - George ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] win32 build
Hi all, perhaps some of you have noticed that since 2 days ago no more windows snapshots have been created. This is due to a switch to mingw-gcc 4.2.1 (from 3.4.5) on the build -system. This is a good sign for our ugly ffmpeg-alignment problems we had been experiencing, rendering the h.263+ codec unusable, however, 4.2.1 is a lot stricter that previous versions, so it will need some effort to streamline our sources to get the windows build back on. Using gcc 4.2.1 on windows also means that finally we will be using the same compiler version for both windows and linux. Any help on bringing back the build will be appreciated. Matthias This message was sent using IMP, the Internet Messaging Program. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] win32 build
Hi Torsten,
the win32 build has been fixed. In order to verify your build environment, you
can try the following patch to switch to my reference revisions which I have
tested.
There are two issues that might appear:
- break of compilation of openldap if concurrency > 1
- break of ffmpeg installation
Both can be safely ignored and compilation resumed with "make".
My setup looks like this (its a little outdated I think)
nsis 2.33-1 Nullsoft Scriptable Install System (modified
mingw32 4.2.1.dfsg-1 Minimalist GNU win32 (cross) compiler
mingw32-binutils 2.17.50-20070129.1-1 minimalist GNU win32 (cross) binutils
mingw32-runtime 3.13-1 Minimalist GNU win32 (cross) runtim
I have fixed the wchar issue in ptlib, it actually was only one #define. Thus no
more patches are required.
Best regards,
Matthias
This message was sent using IMP, the Internet Messaging Program.
Index: Makefile
===
--- Makefile (revision 6181)
+++ Makefile (working copy)
@@ -59,7 +59,7 @@
EKIGA_VER = 2.9
-EKIGA_REV = HEAD
+EKIGA_REV = 6181
EKIGA_URL = http://svn.gnome.org/svn/ekiga/trunk
EKIGA_ARCHIVE := ekiga
EKIGA_DIR = $(BUILDROOT)/ekiga
@@ -70,13 +70,13 @@
EKIGA_INSTALLER := ekiga-setup-${EKIGA_VER}.exe
OPAL_VER:= 3.3.0
-OPAL_REV:= HEAD
+OPAL_REV:= 19980
OPAL_URL:= https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/opal/trunk
OPAL_ARCHIVE := opal
OPAL_DIR:= $(BUILDROOT)/opal
PTLIB_VER:= 2.3.0
-PTLIB_REV:= HEAD
+PTLIB_REV:= 19980
PTLIB_URL:= https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/ptlib/trunk
PTLIB_DIR:= $(BUILDROOT)/ptlib
PTLIB_ARCHIVE := ptlib
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] win32 build
Hi all, is there some more feedback on the latest win32 build available? The only thing that was brought to my attention was that there is a console being opened with some debug information spit out. If thats all trouble that ekiga for windows is having I thing we are doing quite alright... Matthias ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] win32 issues
I just joined back into this list again. I tried to cross compile ekiga
for win32. I was a bit lost what all these branches and tags are meant
for. So I took trunk for ekiga, tag v3_6_1 for opal and tag v2_6_1 for
ptlib. Presumably this is not the place where bug fixing towards an
Ekiga 3.2 for win32 is happening. Could you direct me?
I managed to address some of the win32 build issues which have already
been reported to this list.
1) opal, g722codec.c can not be compiled, as reported by Thierry
Simonnet
http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00082.html .
Preprocessor output indeed shows dllimport functions. This is due to
plugin-config.h not being included as it is e.g. in g726codec.c . See
attached opal_G722dll.diff how one could fix this.
2) ptlib/src/ptlib/common/ptime.cxx issue is due to differences in the
definition of STDAPICALLTYPE in ptime.cxx and getdate.tab.c. At the
level of object files ptime.o was requesting _PTimeParse whereas
getdate.tab.o was providing _ptimepa...@12 . Attached
ptlib_ptime-stdcall.diff lets ptime.cxx use the dll naming scheme, i.e.
_ptimepa...@12
3) Ekiga's ldap support needs libsasl2 as reported by Michael
Cronenworth in
http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00062.html .
This seems a major issue as it may require sasl enabled ldap as well.
cyrus-sasl-2.1.22 can be used in a win32 environment, the Pidgin
developers use it, see
http://developer.pidgin.im/wiki/BuildingWinPidgin#GetthePidginsourcecode . They
even provide binaries compiled with Microsoft tools. So in the Makefile one
could add:
LIBSASL2_VER := 2.1.22
LIBSASL2_DIR := $(BUILDROOT)/cyrus-sasl-$(LIBSASL2_VER)
LIBSASL2_ARCHIVE := cyrus-sasl-$(LIBSASL2_VER).zip
LIBSASL2_URL := http://developer.pidgin.im/static/win32
...
### libsasl2
update-sources::
echo --- Getting libsasl2 ...
$(WGET) -P $(SRCDIR) $(LIBSASL2_URL)/$(LIBSASL2_ARCHIVE)
$(LIBDIR)/libsasl2.a: $(SRCDIR)/$(LIBSASL2_ARCHIVE)
rm -f $(LIBDIR)/libsasl2.a
rm -rf $(LIBSASL2_DIR)
unzip -u $(SRCDIR)/$(LIBSASL2_ARCHIVE) -d $(BUILDROOT)
cp $(LIBSASL2_DIR)/lib/libsasl.lib $(LIBDIR)/libsasl2.a
Fortunately the Mingw Linker seems capable of handling Microsoft .lib
libraries.
I made a preliminary patch to ekiga/configure.ac which allows
configuration --with-libsasl2-dir=$(LIBSASL2_DIR), see attachment. This
allows Ekiga to be compiled with ldap support.
QUESTION ??? Do we have to compile Openldap with sasl support to use it
in Ekiga? Currently the win32 Openldap is configured
--with-cyrus-sasl=no .
I hope this helps a bit getting everything compiled. This seems a
prerequisite for getting things fixed in Ekigas code for win32.
Regards
Michael
diff -ur opal.orig/plugins/audio/G722/g722codec.c opal/plugins/audio/G722/g722codec.c
--- opal.orig/plugins/audio/G722/g722codec.c 2009-03-29 09:03:28.132407340 +0200
+++ opal/plugins/audio/G722/g722codec.c 2009-03-29 08:50:09.520407000 +0200
@@ -24,6 +24,10 @@
* $Date: 2009-01-03 10:24:21 +0100 (Sa, 03. Jan 2009) $
*/
+#ifndef PLUGIN_CODEC_DLL_EXPORTS
+#include "plugin-config.h"
+#endif
+
#include
#include "VoIPCodecs/inttypes.h"
diff -ur opal.orig/plugins/audio/G722/Makefile.in opal/plugins/audio/G722/Makefile.in
--- opal.orig/plugins/audio/G722/Makefile.in 2009-03-29 09:03:28.132407340 +0200
+++ opal/plugins/audio/G722/Makefile.in 2009-03-29 09:00:45.868407000 +0200
@@ -35,6 +35,7 @@
SRCDIR = ./VoIPCodecs
OBJDIR = ./obj
+PLUGINDIR=../..
CC =...@cc@
CXX =...@cxx@
@@ -42,6 +43,7 @@
PLUGINEXT =...@pluginext@
STDCCFLAGS =...@stdccflags@
LDFLAGS =...@ldflags@
+EXTRACFLAGS =-I$(PLUGINDIR)
SRCS += g722codec.c \
$(SRCDIR)/g722_encode.c \
@@ -53,7 +55,7 @@
$(OBJDIR)/%.o : %.c
@mkdir -p $(OBJDIR) >/dev/null 2>&1
- $(CC) -I../../../include $(STDCCFLAGS) $(OPTCCFLAGS) $(CFLAGS) -c $< -o $@
+ $(CC) -I../../../include $(STDCCFLAGS) $(OPTCCFLAGS) $(CFLAGS) $(EXTRACFLAGS) -c $< -o $@
PLUGIN = ./g722_audio_pwplugin.$(PLUGINEXT)
diff -ur ptlib.orig/src/ptlib/common/ptime.cxx ptlib/src/ptlib/common/ptime.cxx
--- ptlib.orig/src/ptlib/common/ptime.cxx 2009-03-29 20:39:41.325934225 +0200
+++ ptlib/src/ptlib/common/ptime.cxx 2009-03-29 20:31:01.416408000 +0200
@@ -545,7 +545,9 @@
extern "C" {
-#ifndef STDAPICALLTYPE
+#ifdef _WIN32
+#define STDAPICALLTYPE __stdcall
+#else
#define STDAPICALLTYPE
#endif
diff -ur ekiga.orig/configure.ac ekiga/configure.ac
--- ekiga.orig/configure.ac 2009-03-29 18:03:09.432404211 +0200
+++ ekiga/configure.ac 2009-03-29 18:02:07.164406000 +0200
@@ -344,7 +344,17 @@
fi
dnl Checking for libsasl2
- AC_CHECK_HEADER(sasl/sasl.h,,AC_MSG_ERROR([*** libsasl2 headers not found]))
+ AC_ARG_WITH(libsasl2-dir, AS_HELP_STRING([--with-libsasl2-dir=PFX],[location of LIBSASL2]), with_libsasl2_dir="$withval", with_libsasl2_dir="/usr")
+
+ dnl Check for the libsasl2 includes presence
+ AC_MSG_CHECKING(for LIBSASL2 includes in ${with_libsasl2_dir}/include/)
+ AC_MSG_RESUL
[Ekiga-devel-list] Win32 DirectX
Ekiga SVN commit 7653 seems not complete. It is apparently based on a discussion on this list in February: http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00042.html . At the moment I work with Ubuntu Intrepid on git master and get circular inclusion of uuids.h and ksuuids.h which will make the ptlib configure fail for DirectX. Attached diff corrects this. An alternative to tweaking DirectX headers may be to use them as they are ment to be used, i.e. preincluding mingw_dshow_port.h, and change ptlib.m4 accordingly. Regards Michael diff -ur ekiga.orig/win32/directx/uuids.h ekiga/win32/directx/uuids.h --- ekiga.orig/win32/directx/uuids.h 2009-04-25 18:22:19.486804883 +0200 +++ ekiga/win32/directx/uuids.h 2009-04-25 18:47:31.934780100 +0200 @@ -18,6 +18,9 @@ // including this file. See wxdebug.cpp in sdk\classes\base. // +#ifndef __UUIDS_INCLUDED__ +#define __UUIDS_INCLUDED__ + #ifndef OUR_GUID_ENTRY #define OUR_GUID_ENTRY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8); @@ -1517,3 +1520,5 @@ #endif // __ENCODER_API_GUIDS__ #undef OUR_GUID_ENTRY + +#endif // __UUIDS_INCLUDED__ ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [WIN32] loudmouth
I tested --enable-loudmouth configure option with loudmouth 1.4.3 for windows. Result : In file included from /root/win32/include/boost/signals/signal8.hpp:24, from /root/win32/include/boost/signal.hpp:27, from /root/win32/include/boost/signals.hpp:9, from ../../lib/engine/framework/services.h:47, from ../../lib/engine/framework/kickstart.h:64, from ../../plugins/loudmouth/loudmouth-main.h:41, from ../../plugins/loudmouth/loudmouth-main.cpp:38: /root/win32/include/boost/signals/signal_template.hpp: In member function âtypename boost::signal8Combiner, Group, GroupCompare, SlotFunction>::result_type boost::signal8GroupCompare, SlotFunction>::operator()(T1, T2, T3, T4, T5, T6, T7, T8)â: /root/win32/include/boost/signals/signal_template.hpp:348: warning: declaration of âresult_typeâ shadows a member of 'this' /root/win32/include/boost/signals/signal_template.hpp: In member function âtypename boost::signal8Combiner, Group, GroupCompare, SlotFunction>::result_type boost::signal8GroupCompare, SlotFunction>::operator()(T1, T2, T3, T4, T5, T6, T7, T8) constâ: /root/win32/include/boost/signals/signal_template.hpp:389: warning: declaration of âresult_typeâ shadows a member of 'this' In file included from /root/win32/include/boost/signals/signal9.hpp:24, from /root/win32/include/boost/signal.hpp:28, from /root/win32/include/boost/signals.hpp:9, from ../../lib/engine/framework/services.h:47, from ../../lib/engine/framework/kickstart.h:64, from ../../plugins/loudmouth/loudmouth-main.h:41, from ../../plugins/loudmouth/loudmouth-main.cpp:38: /root/win32/include/boost/signals/signal_template.hpp: In member function âtypename boost::signal9Combiner, Group, GroupCompare, SlotFunction>::result_type boost::signal9GroupCompare, SlotFunction>::operator()(T1, T2, T3, T4, T5, T6, T7, T8, T9)â: /root/win32/include/boost/signals/signal_template.hpp:348: warning: declaration of âresult_typeâ shadows a member of 'this' /root/win32/include/boost/signals/signal_template.hpp: In member function âtypename boost::signal9Combiner, Group, GroupCompare, SlotFunction>::result_type boost::signal9GroupCompare, SlotFunction>::operator()(T1, T2, T3, T4, T5, T6, T7, T8, T9) constâ: /root/win32/include/boost/signals/signal_template.hpp:389: warning: declaration of âresult_typeâ shadows a member of 'this' In file included from /root/win32/include/boost/signals/signal10.hpp:24, from /root/win32/include/boost/signal.hpp:29, from /root/win32/include/boost/signals.hpp:9, from ../../lib/engine/framework/services.h:47, from ../../lib/engine/framework/kickstart.h:64, from ../../plugins/loudmouth/loudmouth-main.h:41, from ../../plugins/loudmouth/loudmouth-main.cpp:38: /root/win32/include/boost/signals/signal_template.hpp: In member function âtypename boost::signal10T9, T10, Combiner, Group, GroupCompare, SlotFunction>::result_type boost::signal10Group, GroupCompare, SlotFunction>::operator()(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10)â: /root/win32/include/boost/signals/signal_template.hpp:348: warning: declaration of âresult_typeâ shadows a member of 'this' /root/win32/include/boost/signals/signal_template.hpp: In member function âtypename boost::signal10T9, T10, Combiner, Group, GroupCompare, SlotFunction>::result_type boost::signal10Group, GroupCompare, SlotFunction>::operator()(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10) constâ: /root/win32/include/boost/signals/signal_template.hpp:389: warning: declaration of âresult_typeâ shadows a member of 'this' In file included from ../../plugins/loudmouth/loudmouth-chat-simple.h:42, from ../../plugins/loudmouth/loudmouth-dialect.h:40, from ../../plugins/loudmouth/loudmouth-heap.h:41, from ../../plugins/loudmouth/loudmouth-cluster.h:41, from ../../plugins/loudmouth/loudmouth-main.cpp:45: ../../plugins/loudmouth/loudmouth-presentity.h: At global scope: ../../plugins/loudmouth/loudmouth-presentity.h:49: error: expected `)' before â*â token ../../plugins/loudmouth/loudmouth-presentity.h:70: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-presentity.h:70: error: expected â;â before â*â token ../../plugins/loudmouth/loudmouth-presentity.h:72: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-presentity.h:75: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-presentity.h:82: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-presentity.h:82: error: expected â;â before â*â token ../../plugins/loudmouth/loudmouth-presentity.h:83: error: ISO C++ forbids declaration of âLmMessageNodeâ with no type ../../plugins/loudmouth/loudmouth-presentity.h:83: error: expected â;â before â*â token In file included from ../../plugins/loudmouth/loudmouth-cluster.h:41, from ../../plugins/loudmouth/loudmouth-main.cpp:45: ../../plugins/loudmouth/loudmouth-heap.h:53: error: âLmConnectionâ has not been declared ../../plugins/loudmouth/loudmouth-heap.h:72:
Re: [Ekiga-devel-list] win32 build
For sure , somebody posted a NSIS installer 3 months ago , will try to find the site back 2006/8/24, Cedric Krier <[EMAIL PROTECTED]>: Hi,I would like to write a Nullsoft Scriptable Install for ekiga onwindows. But I try to cross-compile with the script on the snapshots site but it doesn't work. It seems there is too much change since thesescript. Is there anybody who have an updated build script for win32.ThanksCédric Krier___ Ekiga-devel-list mailing listEkiga-devel-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- %<--->%Michel memeteausip:[EMAIL PROTECTED] 0491886375 0624808051jabber : [EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Cedric Krier a écrit : > I would like to write a Nullsoft Scriptable Install for ekiga on > windows. But I try to cross-compile with the script on the snapshots > site but it doesn't work. It seems there is too much change since these > script. Is there anybody who have an updated build script for win32. It's been very long since I last tried to cross-compile ; I'll try to have a look at it when I find the time. What was the error message like ? Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
On 25/08/06 10:02 +0200, Julien PUYDT wrote: > Cedric Krier a écrit : > > I would like to write a Nullsoft Scriptable Install for ekiga on > > windows. But I try to cross-compile with the script on the snapshots > > site but it doesn't work. It seems there is too much change since these > > script. Is there anybody who have an updated build script for win32. > > It's been very long since I last tried to cross-compile ; I'll try to > have a look at it when I find the time. > > What was the error message like ? > There was a problem with pwlib, ekiga need version 1.10.1 and the cvs is 1.11.1. Opal's build have changed so the patch in diff doesn't work. Ekiga needs OPAL_H261_QCIF define but it is more in opal. Cédric pgpwnDGkHEIS6.pgp Description: PGP signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Cedric Krier a écrit : > I would like to write a Nullsoft Scriptable Install for ekiga on > windows. But I try to cross-compile with the script on the snapshots > site but it doesn't work. It seems there is too much change since these > script. Is there anybody who have an updated build script for win32. By the way : http://bugzilla.gnome.org/show_bug.cgi?id=339919 Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
michel memeteau a écrit : > For sure , somebody posted a NSIS installer 3 months ago , will try to > find the site back Was it Michael Rickmann ? Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
I would like to collaborate with any and all on the win32 port of ekiga. I have cross-compiled multiple versions from CVS with some degree of success. I am currently trying to setup a debug environment in win32 XP but haven't been able to import symbols properly. Versions of ekiga around 20060506 seem to have good quality audio and video but seem crashy here. I'm building a new header / lib directory for a fresh build in the next few weeks. And there's the libpt static link issue. But, this is a great C++ project to learn some of pwlib tricks! From: Julien PUYDT <[EMAIL PROTECTED]> Reply-To: Ekiga development mailing list To: Ekiga development mailing list Subject: Re: [Ekiga-devel-list] win32 build Date: Fri, 25 Aug 2006 11:55:23 +0200 michel memeteau a écrit : > For sure , somebody posted a NSIS installer 3 months ago , will try to > find the site back Was it Michael Rickmann ? Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Le samedi 26 août 2006 à 13:04 +, M. Renee Hopkins a écrit : > I would like to collaborate with any and all on the win32 port of ekiga. I > have cross-compiled multiple versions from CVS with some degree of success. > > I am currently trying to setup a debug environment in win32 XP but haven't > been able to import symbols properly. > > Versions of ekiga around 20060506 seem to have good quality audio and video > but seem crashy here. I'm building a new header / lib directory for a fresh You should probably update. My colleague has been making heavy tests and couldn't really crash the newest release. If you can crash it, please investigate :) > build in the next few weeks. And there's the libpt static link > issue. > > But, this is a great C++ project to learn some of pwlib tricks! > > > > > >From: Julien PUYDT <[EMAIL PROTECTED]> > >Reply-To: Ekiga development mailing list > >To: Ekiga development mailing list > >Subject: Re: [Ekiga-devel-list] win32 build > >Date: Fri, 25 Aug 2006 11:55:23 +0200 > > > >michel memeteau a écrit : > > > For sure , somebody posted a NSIS installer 3 months ago , will try to > > > find the site back > > > >Was it Michael Rickmann ? > > > >Snark > >___ > >Ekiga-devel-list mailing list > >Ekiga-devel-list@gnome.org > >http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > > > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_FOSDEM 2006: http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Thanks for the reply. I'll look into a recent CVS snapshot to cross build. However, in the last few months, the recent CVS had much CPU overhead and tended to garble audio and video a bit on WIN32 in default video size and either speex or ilbc codec. Only after going back to the May CVS did the performance return to "usual". But, keep in mind, I've had some errors here too on my part, such as the wrong includes accidentally being used :(. But, I noticed one of the ekiga.exe from ekiga.org had the libpt static VFW bug? in it too, i.e. VFW devices are not enumerated on ekiga.exe win32 when you go into preferences. I traced this down to perhaps a mingw trick? when building libpt.a but did not resolve it completely. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Hi, Here is an nsi script to generate a setup.exe for ekiga on win32. To run it: # makensis ekiga.nsi I have put the different license for the dll's. I don't know if it is right. You can try the exe here : http://ced.homedns.org/Ekiga-setup.exe Cédric !include "MUI.nsh" Name "Ekiga" OutFile "Ekiga-setup.exe" InstallDir $PROGRAMFILES\Ekiga InstallDirRegKey HKLM "Software\Ekiga" "Install_Dir" Var MUI_TEMP Var STARTMENU_FOLDER !define MUI_ABORTWARNING ;Page directory ;Page instfiles ;UninstPage uninstConfirm ;UninstPage instfiles !insertmacro MUI_PAGE_LICENSE License.txt !insertmacro MUI_PAGE_LICENSE License_openldap.txt !insertmacro MUI_PAGE_LICENSE License_libxml2.txt !insertmacro MUI_PAGE_LICENSE License_SDL.txt !insertmacro MUI_PAGE_DIRECTORY !define MUI_STARTMENUPAGE_REGISTRY_ROOT "HKCU" !define MUI_STARTMENUPAGE_REGISTRY_KEY "Software\Ekiga" !define MUI_STARTMENUPAGE_REGISTRY_VALUENAME "Ekiga" !insertmacro MUI_PAGE_STARTMENU Application $STARTMENU_FOLDER !insertmacro MUI_PAGE_INSTFILES !insertmacro MUI_UNPAGE_CONFIRM !insertmacro MUI_UNPAGE_INSTFILES !insertmacro MUI_LANGUAGE "English" Section "Ekiga" SectionIn RO SetOutPath "$INSTDIR" File ekiga.exe File liblber.dll File libldap_r.dll File libxml2-2.dll File SDL.dll File INSTALL_Gtk.txt SetOutPath "$INSTDIR\ekiga" File ekiga\ekiga.schemas SetOutPath "$INSTDIR\pixmaps" File pixmaps\ekiga.png SetOutPath "$INSTDIR\pixmaps\ekiga" File pixmaps\ekiga\ekiga-logo.png SetOutPath "$INSTDIR\sounds\ekiga" File sounds\ekiga\busytone.wav File sounds\ekiga\dialtone.wav File sounds\ekiga\newmessage.wav File sounds\ekiga\ring.wav File sounds\ekiga\voicemail.wav ; WriteRegStr HKLM SOFTWARE\Ekiga "Install_Dir" "$INSTDIR" WriteRegStr HKCU "Software\Ekiga" "" "$INSTDIR" ; WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\Ekiga" "DisplayName" "Ekiga" ; WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\Ekiga" "UninstallString" '"$INSTDIR\uninstall.exe"' ; WriteRegDWORD HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\Ekiga" "NoModify" 1 ; WriteRegDWORD HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\Ekiga" "NoRepair" 1 WriteUninstaller "uninstall.exe" !insertmacro MUI_STARTMENU_WRITE_BEGIN Application CreateDirectory "$SMPROGRAMS\$STARTMENU_FOLDER" CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\Ekiga.lnk" "$INSTDIR\ekiga.exe" CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\Uninstall.lnk" "$INSTDIR\Uninstall.exe" !insertmacro MUI_STARTMENU_WRITE_END SectionEnd ;Section "Start Menu Shortcuts" ; ; SetOutPath $INSTDIR ; SetShellVarContext all ; CreateDirectory "$SMPROGRAMS\Ekiga" ; CreateShortCut "$SMPROGRAMS\Ekiga\Ekiga.lnk" "$INSTDIR\ekiga.exe" "" "$INSTDIR\ekiga.exe" 0 ; CreateShortCut "$SMPROGRAMS\Ekiga\Uninstall.lnk" "$INSTDIR\uninstall.exe" "" "$INSTDIR\uninstall.exe" 0 ; ;SectionEnd Section "Uninstall" ; DeleteRegKey HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\Ekiga" ; DeleteRegKey HKLM SOFTWARE\Ekiga Delete "$INSTDIR\ekiga.exe" Delete "$INSTDIR\liblber.dll" Delete "$INSTDIR\libldap_r.dll" Delete "$INSTDIR\libxml2-2.dll" Delete "$INSTDIR\SDL.dll" Delete "$INSTDIR\INSTALL_Gtk.txt" Delete "$INSTDIR\ekiga\ekiga.schemas" Delete "$INSTDIR\pixmaps\ekiga.png" Delete "$INSTDIR\pixmaps\ekiga\ekiga-logo.png" Delete "$INSTDIR\sounds\ekiga\busytone.wav" Delete "$INSTDIR\sounds\ekiga\dialtone.wav" Delete "$INSTDIR\sounds\ekiga\newmessage.wav" Delete "$INSTDIR\sounds\ekiga\ring.wav" Delete "$INSTDIR\sounds\ekiga\voicemail.wav" Delete "$INSTDIR\uninstall.exe" Delete "$INSTDIR\stderr.txt" Delete "$INSTDIR\stdout.txt" RMDir "$INSTDIR\ekiga" RMDir "$INSTDIR\pixmaps\ekiga" RMDir "$INSTDIR\pixmaps" RMDir "$INSTDIR\sounds\ekiga" RMDir "$INSTDIR\sounds" RMDir "$INSTDIR" ; SetShellVarContext all ; Delete "$SMPROGRAMS\Ekiga\*.*" ; RMDir "$SMPROGRAMS\Ekiga" !insertmacro MUI_STARTMENU_GETFOLDER Application $MUI_TEMP Delete "$SMPROGRAMS\$MUI_TEMP\Ekiga.lnk" Delete "$SMPROGRAMS\$MUI_TEMP\Uninstall.lnk" StrCpy $MUI_TEMP "$SMPROGRAMS\$MUI_TEMP" startMenuDeleteLoop: ClearErrors RMDir $MUI_TEMP GetFullPathName $MUI_TEMP "$MUI_TEMP\.." ifErrors startMenuDeleteLoopDone StrCmp $MUI_TEMP $SMPROGRAMS startMenuDeleteLoopDone startMenuDeleteLoop startMenuDeleteLoopDone: DeleteRegKey /ifempty HKCU "Software\Ekiga" SectionEnd pgpe1zzqR2poP.pgp
Re: [Ekiga-devel-list] win32 build
Hi, Thanks for your contribution! Le mardi 29 août 2006 à 14:40 +0200, Cedric Krier a écrit : > Hi, > > Here is an nsi script to generate a setup.exe for ekiga on win32. > To run it: # makensis ekiga.nsi > I have put the different license for the dll's. I don't know if it is > right. > > You can try the exe here : > > http://ced.homedns.org/Ekiga-setup.exe > > Cédric > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- _ Damien Sandras (o- //\ Ekiga Softphone: http://www.ekiga.org/ v_/_FOSDEM 2006: http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Matthias Schneider a écrit : > Hi all, > about the windows port of ekiga I have some questions, I would like to set up > a > build environment.I am aware that I need ptlib_win32, opal and of course > ekiga. > Do I need anything else installed except for minGW and MSYS? starting with > ptlib > I found the problem that although I may run configure.exe I do not get a > makefile.. It would be very nice if someone could give me some hints.. Also I > would like to know know more about the state of the current windows port > (talking about svn head) Did you have a look at the ekiga_build.zip file we have available, with a nice Makefile which does it all ? Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Hi Julien, yes I tried, sorry this email got delayed quite some time, I had quite some troubles with the mailing list and my university changing my email address without notifying me (by the way thank you Damien for fixing my account). I spend quite some hours trying to build ekiga (especially openldap), I had to do some changes for openldap to compile (see enclosed patches, one for the makefile and one for openldaps configure.in (I dont know the regex library chek always faild although it was looking in the right place so I commented it out). It would be nice if some could comment on my (mostly ugly) "fixes". Also perhaps one should emphasize that the build script is for cross-compilation - it wasnt obvious at the first sight for me. Also please ignore my other post, meanwhile I found out about the console output on windows. Bye Matthias Quoting Julien Puydt <[EMAIL PROTECTED]>: > Matthias Schneider a écrit : > > Hi all, > > about the windows port of ekiga I have some questions, I would like to set > up a > > build environment.I am aware that I need ptlib_win32, opal and of course > ekiga. > > Do I need anything else installed except for minGW and MSYS? starting with > ptlib > > I found the problem that although I may run configure.exe I do not get a > > makefile.. It would be very nice if someone could give me some hints.. Also > I > > would like to know know more about the state of the current windows port > > (talking about svn head) > > Did you have a look at the ekiga_build.zip file we have available, with > a nice Makefile which does it all ? > > Snark > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > This message was sent using IMP, the Internet Messaging Program. --- configure.in.sav 2006-07-28 16:53:03.0 +0200 +++ configure.in 2007-02-25 00:36:40.0 +0100 @@ -1025,8 +1025,8 @@ if test "$ac_cv_header_regex_h" != yes ; then AC_MSG_ERROR([POSIX regex.h required.]) fi -AC_SEARCH_LIBS(regfree, [regex gnuregex], - :, AC_MSG_ERROR([POSIX regex required.])) +dnl AC_SEARCH_LIBS(regfree, [regex gnuregex], +dnl :, AC_MSG_ERROR([POSIX regex required.])) OL_POSIX_REGEX if test "$ol_cv_c_posix_regex" = no ; then --- Makefile 2007-01-15 22:14:00.0 +0100 +++ Makefile.new 2007-02-26 20:32:09.0 +0100 @@ -152,7 +152,7 @@ echo "--- Getting libregex..." rm -f lib/libregex.a regex/regex.h $(INCLUDE_DIR)/regex.h mkdir -p regex - cd regex/;for i in regex.c regexec.c regex.h regex_internal.c regex_internal.h regcomp.c alloca_.h alloca.c strcase.h;do \ + cd regex/;for i in regex.c regexec.c regex.h regex_internal.c regex_internal.h regcomp.c alloca_.h alloca.c strcase.h localcharset.h;do \ $(WGET) http://cvs.savannah.nongnu.org/viewcvs/*checkout*/gnulib/gnulib/lib/$$i ;\ done mv regex/alloca_.h regex/alloca.h @@ -219,7 +219,8 @@ #-$(MAKE) -C $(OPENLDAP_DIR) clean rm -f lib/libldap_r.dll ln -sf $(INCLUDE_DIR)/regex.h $(OPENLDAP_DIR)/include/ - cd $(OPENLDAP_DIR);./configure --with-cyrus-sasl=no --enable-bdb=no --enable-hdb=no $(confflags) + echo "$(MAKE) $(MAKEOPTS) -C $(OPENLDAP_DIR) depend" + cd $(OPENLDAP_DIR);./configure --with-cyrus-sasl=no --enable-bdb=no --enable-hdb=no --with-yielding_select=yes $(confflags) $(MAKE) $(MAKEOPTS) -C $(OPENLDAP_DIR) depend touch $@ ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Compile
George Lee a écrit : > I am new to Ekiga and I am looking for more of a step-by-step info on how to > compile Ekiga in Windows XP environment. I have tried to use the ekiga_build > scripts and I had no success. I did a make on the cygwin command prompt and > it gave me these: Our build scripts are meant for cross-compilation on GNU/Linux for win32. Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 build broken?
Dear list! I am currently trying this: http://wiki.ekiga.org/index.php/Cross-compile_Win32 but fail: # make make -j1 -C /usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib make[1]: Entering directory `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' make all-am make[2]: Entering directory `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' make[2]: *** No rule to make target `src/ptclib/url.cxx', needed by `url.lo'. Stop. make[2]: Leaving directory `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' make: *** [/usr/local/src/ekiga-win32/ekiga-win32-cross/lib/libpt.a] Error 2 Is that anything obvious or should I work with the PTLib developers on that? I need to say, I am having a hard time following all these PTLib / PWLib versions in all that different places. Regards, Torsten ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] win32 build updated
Hi all, due to the huge demand of the win32 build I have updated Ekiga's Makefile to work with current ptlib, opal and ekiga svn trunk. The only issue remaining are the changes made in revision 18828: Fixed UNICODE support issue where wchar_t is not precisely the same thing as the WORD (aka unsigned short) type previously used in strings. and the corresponding OPAL commit. It completely breaks Ekiga's cross-compilation with errors like this: ./src/ptclib/asner.cxx: In member function 'PBoolean PASN_BMPString::IsLegalCharacter(WORD)': ./src/ptclib/asner.cxx:1490: error: invalid conversion from 'const short unsigned int*' to 'const wchar_t*' In file included from ./src/ptclib/asner.cxx:2498: ./src/ptclib/asnber.cxx: In member function 'void PASN_BMPString::EncodeBER(PBER_Stream&) const': ./src/ptclib/asnber.cxx:246: error: invalid cast from type 'const PWCharArray' to type 'const wchar_t*' [...] ./src/ptlib/common/contain.cxx: In constructor 'PString::PString(const PWCharArray&)': ./src/ptlib/common/contain.cxx:631: error: invalid conversion from 'const short unsigned int*' to 'const wchar_t*' ./src/ptlib/common/contain.cxx:631: error: initializing argument 1 of 'void PString::InternalFromUCS2(const wchar_t*, int)' ./src/ptlib/common/contain.cxx: In member function 'PWCharArray PString::AsUCS2() const': ./src/ptlib/common/contain.cxx:1695: error: invalid conversion from 'short unsigned int*' to 'WCHAR*' ./src/ptlib/common/contain.cxx:1695: error: initializing argument 5 of 'int MultiByteToWideChar(UINT, DWORD, const CHAR*, int, WCHAR*, int)' Craig, Robert, I do not know if you are both subscribed to this list, but if you are, could you give it a look? In case someone wants to build a win32 ekiga he/she can do the following: - get the buildscript like described on the wiki - make update-sources - aplly the enclosed patches to opal and ptlib, which revert the WideChar commits - make The resulting executable and installer have not been tested by me though, so no guarantee it will work... I have also updated the wiki, separating 2.0 stuff from 3.0 stuff. However, we will probably drop the 2.0 stuff since it is coming to an end-of-life... Matthias This message was sent using IMP, the Internet Messaging Program. win32_opal.patch Description: Binary data win32_ptlib.patch Description: Binary data ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Hi Matthias! Thank you for that. I did a test run. > There are two issues that might appear: > - break of compilation of openldap if concurrency > 1 Did not appear. > - break of ffmpeg installation Did appear. After that, I ran all the way into my nsis error which is known from earlier: > File: "ekiga.exe" [compress]/bin/sh: line 4: 11503 Bus error > > ( makensis -DEKIGA_VERSION=2.9 > -DEKIGA_DIR=/usr/local/src/ekiga-win32/ekiga > -DBUILDROOT=/usr/local/src/ekiga-win32 > -DINSTALLER_DIR=/usr/local/src/ekiga-win32/nsisinstaller > -DLIB_DIR=/usr/local/src/ekiga-win32/lib > -DTARGET_DIR=/usr/local/src/ekiga-win32/dist -DCROSS_COMPILING=true > -DWITH_GTK=true -DGTK_VERSION=2.10.11 > -DNSISSYSTEMDIR=/usr/share/nsis/Contrib/Modern\ UI > -DNSISPLUGINDIR=/usr/local/src/ekiga-win32/nsisplugins > /usr/local/src/ekiga-win32/nsisinstaller/ekiga.nsi ) The error itself is [compress]/bin/sh: line 4: 11503 Bus error I attribute that to my machine and will check out. It's not what I thought or what other posts on that subject indicated, i.e. a 32 / 64 bit problem. This time I built on a 32 bit system. But at least your fixes seem to work, thank you. I think I will hunt that "Bus error" problem, then use this build as a reference and check this out with switching from pinned SVN revisions to HEAD again. Regards, Torsten Original-Nachricht > Datum: Sun, 13 Apr 2008 10:22:33 +0200 > Von: Matthias Schneider <[EMAIL PROTECTED]> > An: Ekiga development mailing list > Betreff: [Ekiga-devel-list] win32 build > Hi Torsten, > > the win32 build has been fixed. In order to verify your build environment, > you > can try the following patch to switch to my reference revisions which I > have > tested. > > There are two issues that might appear: > - break of compilation of openldap if concurrency > 1 > - break of ffmpeg installation > > Both can be safely ignored and compilation resumed with "make". > My setup looks like this (its a little outdated I think) > > nsis 2.33-1 Nullsoft Scriptable Install System (modified > mingw32 4.2.1.dfsg-1 Minimalist GNU win32 (cross) compiler > mingw32-binutils 2.17.50-20070129.1-1 minimalist GNU win32 (cross) > binutils > mingw32-runtime 3.13-1 Minimalist GNU win32 (cross) runtim > > I have fixed the wchar issue in ptlib, it actually was only one #define. > Thus no > more patches are required. > > Best regards, > Matthias > > > > This message was sent using IMP, the Internet Messaging Program. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Hi Matthias! Some good news: For the first time ever, I was able to produce an ekiga-setup-2.9.exe file! That "Bus error" was a pretty strange and stupid one. VServers by default have an in-memory 16 MB /tmp partition. That's just too small. A simple umount /tmp will make /tmp a folder in the disk file system, doing away with that bottleneck. After that, it worked. I am currently downloading the installer file onto my Windows machine for a smoke test. (Installing, starting, hoping to not see any crashes immediately.) Just to remember what's still open: 1. Find a solution for automake detection. 2. Switch from pinned versions back to HEAD. 3. Deal with that safely ignoreable issues in OpenLDAP and ffmpeg. (They would break any automated nightly build.) 4. I still had to patch that Modern UI System.nsh file for that branding image error. Well, let's test what we compiled first. Regards, Torsten P.S.: On the subject of a common Linux / Windows (maybe also BSD, Solaris, MacSO, ... build): I haven't analyzed yet what's the conceptual difference between the Win32 and the "normal" build. But without any further investigation, shouldn't something like Gentoo Linux provide some template? Original-Nachricht > Datum: Sun, 13 Apr 2008 10:22:33 +0200 > Von: Matthias Schneider <[EMAIL PROTECTED]> > An: Ekiga development mailing list > Betreff: [Ekiga-devel-list] win32 build > Hi Torsten, > > the win32 build has been fixed. In order to verify your build environment, > you > can try the following patch to switch to my reference revisions which I > have > tested. > > There are two issues that might appear: > - break of compilation of openldap if concurrency > 1 > - break of ffmpeg installation > > Both can be safely ignored and compilation resumed with "make". > My setup looks like this (its a little outdated I think) > > nsis 2.33-1 Nullsoft Scriptable Install System (modified > mingw32 4.2.1.dfsg-1 Minimalist GNU win32 (cross) compiler > mingw32-binutils 2.17.50-20070129.1-1 minimalist GNU win32 (cross) > binutils > mingw32-runtime 3.13-1 Minimalist GNU win32 (cross) runtim > > I have fixed the wchar issue in ptlib, it actually was only one #define. > Thus no > more patches are required. > > Best regards, > Matthias > > > > This message was sent using IMP, the Internet Messaging Program. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Quoting Torsten Schlabach <[EMAIL PROTECTED]>: > Hi again! > > Smoke test results: > > - Installation is fine, except, it's complaining it cannot remove my old > version. So I installed the new version over the old one. Not sure if this > will be the reason for some of the problems I have. Maybe your configuration (in some xml file) will ber very corrupted. Perhaps you can start with a fresh one, i.e. delete and reinstall? > - A new GTK+ runtime was installed, then Ekiga installed itself and started. > > The configuration assistent broke with some "assertion failed" messages. But > ignoring them, I was able to get the app started. It registered successfully > with my SIP accounts which I had configured using 2.0.11. Can you find out what assertions exactly failed in case its not related to the old config? > Trying to make a call is a bit pointless because it does not recognize any > audio devices yet. Hm, but 2.x shows devices? Can you post a -d4 of a startup? > > Well, I guess it will make more sense to test this on a clean Windows machine > with no pre-installed old version. I will take care of that. > > Another question: Why is the version number 2.9, not 3.0? I guess because 3.00 is not released yet? Anyway its just cosmetics... > Regards, > Torsten > > Original-Nachricht > > Datum: Sun, 13 Apr 2008 10:22:33 +0200 > > Von: Matthias Schneider <[EMAIL PROTECTED]> > > An: Ekiga development mailing list > > Betreff: [Ekiga-devel-list] win32 build > > > Hi Torsten, > > > > the win32 build has been fixed. In order to verify your build environment, > > you > > can try the following patch to switch to my reference revisions which I > > have > > tested. > > > > There are two issues that might appear: > > - break of compilation of openldap if concurrency > 1 > > - break of ffmpeg installation > > > > Both can be safely ignored and compilation resumed with "make". > > My setup looks like this (its a little outdated I think) > > > > nsis 2.33-1 Nullsoft Scriptable Install System (modified > > mingw32 4.2.1.dfsg-1 Minimalist GNU win32 (cross) compiler > > mingw32-binutils 2.17.50-20070129.1-1 minimalist GNU win32 (cross) > > binutils > > mingw32-runtime 3.13-1 Minimalist GNU win32 (cross) runtim > > > > I have fixed the wchar issue in ptlib, it actually was only one #define. > > Thus no > > more patches are required. > > > > Best regards, > > Matthias > > > > > > > > This message was sent using IMP, the Internet Messaging Program. > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > This message was sent using IMP, the Internet Messaging Program. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Hi again! Smoke test results: - Installation is fine, except, it's complaining it cannot remove my old version. So I installed the new version over the old one. Not sure if this will be the reason for some of the problems I have. - A new GTK+ runtime was installed, then Ekiga installed itself and started. The configuration assistent broke with some "assertion failed" messages. But ignoring them, I was able to get the app started. It registered successfully with my SIP accounts which I had configured using 2.0.11. Trying to make a call is a bit pointless because it does not recognize any audio devices yet. Well, I guess it will make more sense to test this on a clean Windows machine with no pre-installed old version. I will take care of that. Another question: Why is the version number 2.9, not 3.0? Regards, Torsten Original-Nachricht > Datum: Sun, 13 Apr 2008 10:22:33 +0200 > Von: Matthias Schneider <[EMAIL PROTECTED]> > An: Ekiga development mailing list > Betreff: [Ekiga-devel-list] win32 build > Hi Torsten, > > the win32 build has been fixed. In order to verify your build environment, > you > can try the following patch to switch to my reference revisions which I > have > tested. > > There are two issues that might appear: > - break of compilation of openldap if concurrency > 1 > - break of ffmpeg installation > > Both can be safely ignored and compilation resumed with "make". > My setup looks like this (its a little outdated I think) > > nsis 2.33-1 Nullsoft Scriptable Install System (modified > mingw32 4.2.1.dfsg-1 Minimalist GNU win32 (cross) compiler > mingw32-binutils 2.17.50-20070129.1-1 minimalist GNU win32 (cross) > binutils > mingw32-runtime 3.13-1 Minimalist GNU win32 (cross) runtim > > I have fixed the wchar issue in ptlib, it actually was only one #define. > Thus no > more patches are required. > > Best regards, > Matthias > > > > This message was sent using IMP, the Internet Messaging Program. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Quoting Torsten Schlabach <[EMAIL PROTECTED]>: > Hi Matthias! > > Some good news: > > For the first time ever, I was able to produce an ekiga-setup-2.9.exe file! > > That "Bus error" was a pretty strange and stupid one. VServers by default > have an in-memory 16 MB /tmp partition. That's just too small. A simple > umount /tmp will make /tmp a folder in the disk file system, doing away with > that bottleneck. > > After that, it worked. I am currently downloading the installer file onto my > Windows machine for a smoke test. (Installing, starting, hoping to not see > any crashes immediately.) > > Just to remember what's still open: > > 1. Find a solution for automake detection. > 2. Switch from pinned versions back to HEAD. > 3. Deal with that safely ignoreable issues in OpenLDAP and ffmpeg. (They > would break any automated nightly build.) > 4. I still had to patch that Modern UI System.nsh file for that branding > image error. I am sorry to say that but I will not have time to work on any of these issues in the near future. So I will have to depend on you I suppose... About switching to head , any major commit in opal or ptlib will require manual intervention from a win32 builder here... > > Well, let's test what we compiled first. > > Regards, > Torsten > > P.S.: On the subject of a common Linux / Windows (maybe also BSD, Solaris, > MacSO, ... build): I haven't analyzed yet what's the conceptual difference > between the Win32 and the "normal" build. But without any further > investigation, shouldn't something like Gentoo Linux provide some template? The build environment of opal and ptlib is completely separate between linux and windows ... This means it will have to be adapted at every major commit... > Original-Nachricht ---- > > Datum: Sun, 13 Apr 2008 10:22:33 +0200 > > Von: Matthias Schneider <[EMAIL PROTECTED]> > > An: Ekiga development mailing list > > Betreff: [Ekiga-devel-list] win32 build > > > Hi Torsten, > > > > the win32 build has been fixed. In order to verify your build environment, > > you > > can try the following patch to switch to my reference revisions which I > > have > > tested. > > > > There are two issues that might appear: > > - break of compilation of openldap if concurrency > 1 > > - break of ffmpeg installation > > > > Both can be safely ignored and compilation resumed with "make". > > My setup looks like this (its a little outdated I think) > > > > nsis 2.33-1 Nullsoft Scriptable Install System (modified > > mingw32 4.2.1.dfsg-1 Minimalist GNU win32 (cross) compiler > > mingw32-binutils 2.17.50-20070129.1-1 minimalist GNU win32 (cross) > > binutils > > mingw32-runtime 3.13-1 Minimalist GNU win32 (cross) runtim > > > > I have fixed the wchar issue in ptlib, it actually was only one #define. > > Thus no > > more patches are required. > > > > Best regards, > > Matthias > > > > > > > > This message was sent using IMP, the Internet Messaging Program. > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > This message was sent using IMP, the Internet Messaging Program. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Le mercredi 12 novembre 2008 à 14:07 +, Matthias Schneider a écrit : > Hi all, > > is there some more feedback on the latest win32 build available? The only > thing that was brought to my attention was that there is a console being > opened with some debug information spit out. If thats all trouble that ekiga > for windows is having I thing we are doing quite alright... > > Matthias Unfortunately, no confirmation on my side of this working yet... > > > > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > -- Me joindre en téléphonie IP / vidéoconférence ? sip:[EMAIL PROTECTED] Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
> Hi all, > > is there some more feedback on the latest win32 build available? The only > thing that was brought to my attention was that there is a console being > opened with some debug information spit out. If thats all trouble that ekiga > for windows is having I thing we are doing quite alright... My house mate got him new Vista laptop delivered today so I actually have a windows machine in the house to test on :-) There is a console being opened with "gm_conf_get_string assertion failed" errors which I presume is because being a new install they don't exist. I have a screen shot I can email you if that is any help. I also added my ekiga.net account and saw that it registered and then removed it (so he can register his own when he gets around to it) straight away (no restart between any of it) and that caused it to crash. Other than that it all looks very reasonable. With luck will get more chance to test it a little later. Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
>> is there some more feedback on the latest win32 build available? The only >> thing that was brought to my attention was that there is a console being >> opened with some debug information spit out. If thats all trouble that ekiga >> for windows is having I thing we are doing quite alright... > > My house mate got him new Vista laptop delivered today so I actually > have a windows machine in the house to test on :-) > > There is a console being opened with "gm_conf_get_string assertion > failed" errors which I presume is because being a new install they > don't exist. I have a screen shot I can email you if that is any help. > I also added my ekiga.net account and saw that it registered and then > removed it (so he can register his own when he gets around to it) > straight away (no restart between any of it) and that caused it to > crash. Other than that it all looks very reasonable. With luck will > get more chance to test it a little later. Oh, and it would be a little bit more user friendly if the download link for windows went straight to the dir with the builds in them rather going to a text file with a link going to it. Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build
Le mercredi 12 novembre 2008 à 14:07 +, Matthias Schneider a écrit : > Hi all, > > is there some more feedback on the latest win32 build available? The only > thing that was brought to my attention was that there is a console being > opened with some debug information spit out. If thats all trouble that ekiga > for windows is having I thing we are doing quite alright... > Hi Matthias, I just had a long conversion with my friend using windows vista 64 bits and it worked quite good. We were using speex + theora. We had some crashes (well 4 crashes in 2 hours of discussion, 2 on my side and 2 on his side too, but unfortunately we do not have backtraces for it). Is the instructions here still useful: http://wiki.ekiga.org/index.php/Debugging_Ekiga#How_to_send_us_a_backtrace_from_a_crash_2 ?? My friend is willing to help beta testing. One major issue seems to be with the screen saver under windows. It seems it made ekiga crash. There is also the gconf issue already reported when installing. Thank you for your work! > Matthias > > > > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > -- Me joindre en téléphonie IP / vidéoconférence ? sip:[EMAIL PROTECTED] Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 building tools
Hello, I will attempt to build the Win32 package for you guys, but first I'd like to know if there is any place where I can grab the NSIS installer script or the list of packages that were used during compiling. I can fair enough on my own to build it, but I'd like to match the feature set of the current build. Thanks, Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 issues
Michael Rickmann a écrit : I made a preliminary patch to ekiga/configure.ac which allows configuration --with-libsasl2-dir=$(LIBSASL2_DIR), see attachment. This allows Ekiga to be compiled with ldap support. Applied, thanks! Snarj ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 issues
Michael Rickmann wrote: I just joined back into this list again. I tried to cross compile ekiga for win32. I was a bit lost what all these branches and tags are meant for. So I took trunk for ekiga, tag v3_6_1 for opal and tag v2_6_1 for Very well explained at http://wiki.ekiga.org, section Download sources. ptlib. Presumably this is not the place where bug fixing towards an Ekiga 3.2 for win32 is happening. Could you direct me? It's a good place! I managed to address some of the win32 build issues which have already been reported to this list. Great! 1) opal, g722codec.c can not be compiled, as reported by Thierry Simonnet http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00082.html . Preprocessor output indeed shows dllimport functions. This is due to plugin-config.h not being included as it is e.g. in g726codec.c . See attached opal_G722dll.diff how one could fix this. Sigh, this has not been fixed until now, is that right? Could you please report a bug to https://sourceforge.net/tracker/?group_id=204472&atid=989748 ? 2) ptlib/src/ptlib/common/ptime.cxx issue is due to differences in the definition of STDAPICALLTYPE in ptime.cxx and getdate.tab.c. At the level of object files ptime.o was requesting _PTimeParse whereas getdate.tab.o was providing _ptimepa...@12 . Attached ptlib_ptime-stdcall.diff lets ptime.cxx use the dll naming scheme, i.e. _ptimepa...@12 Same as above. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 issues
Ok I have submitted the two bug reports https://sourceforge.net/tracker/?func=detail&aid=2728003&group_id=204472&atid=989748 https://sourceforge.net/tracker/?func=detail&aid=2728037&group_id=204472&atid=989748 Another Win32 issue, the "crash on exit" one: I have been fighting to obtain a debug built of ekiga which allows gdb to backtrace across different dlls. For others who try the same: in the win32 Makefile autogen.sh with --enable-opal-debug instead of --enable-debug and use -gstabs instead of -g as the debugging flag. Attached gdb backtrace was produced on an XP home machine using the gdb contained in https://sourceforge.net/project/downloading.php?group_id=204414&use_mirror=switch&filename=gdbserver-6.8-002-20090131.exe&a=88862589 To me the underlying bug appears obscure. Apparenly, it happens when the sigc++ objects for the address book are destroyed. Can anyone suggest a strategy how to approach this crash? Regards Michael Program received signal SIGSEGV, Segmentation fault. 0xfeeefeee in ?? () (gdb) bt #0 0xfeeefeee in ?? () #1 0x07ef2183 in sigc::internal::slot_rep::disconnect (this=0x86ad470) at functors/slot_base.cc:50 #2 0x07ef21c3 in sigc::internal::slot_rep::notify (data=0x86ad470) at functors/slot_base.cc:63 #3 0x07ef1b51 in sigc::internal::trackable_callback_list::~trackable_callback_list (this=0x86d66b8) at trackable.cc:89 #4 0x07ef1c14 in sigc::trackable::notify_callbacks (this=0x865311c) at trackable.cc:67 #5 0x07ef1c57 in sigc::trackable::~trackable (this=0x865311c) at trackable.cc:51 #6 0x07ef1472 in sigc::signal_base::~signal_base (this=0x865311c) at signal_base.cc:107 #7 0x008ca3de in sigc::signal2, gmref_ptr, sigc::nil>::~signal2 () #8 0x004762bc in Ekiga::ContactCore::~ContactCore (this=0x8653110) at ../../../lib/engine/addressbook/contact-core.cpp:51 #9 0x0093ace0 in GmRefCounted::unreference () #10 0x0092fe1a in gmref_ptr::reset () #11 0x0093039d in gmref_ptr::~gmref_ptr () #12 0x00925825 in __gnu_cxx::new_allocator >::destroy() #13 0x00a086a0 in std::list, std::allocator > >::_M_erase () #14 0x00a0875d in std::list, std::allocator > >::pop_front () #15 0x0043c35f in Ekiga::ServiceCore::~ServiceCore (this=0x8678ee8) at ../../../lib/engine/framework/services.cpp:46 #16 0x00457112 in engine_stop () at engine.cpp:314 #17 0x0042299f in GnomeMeeting::StopEngine (this=0xb3a0d0) at ekiga.cpp:248 #18 0x0040f4b4 in main (argc=2359232, argv=0x40f59f) at gui/main.cpp:4575 (gdb)___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 issues
Michael Rickmann wrote: Ok I have submitted the two bug reports https://sourceforge.net/tracker/?func=detail&aid=2728003&group_id=204472&atid=989748 https://sourceforge.net/tracker/?func=detail&aid=2728037&group_id=204472&atid=989748 Another Win32 issue, the "crash on exit" one: I have been fighting to obtain a debug built of ekiga which allows gdb to backtrace across different dlls. For others who try the same: in the win32 Makefile autogen.sh with --enable-opal-debug instead of --enable-debug and use -gstabs instead of -g as the debugging flag. Attached gdb backtrace was produced on an XP home machine using the gdb contained in https://sourceforge.net/project/downloading.php?group_id=204414&use_mirror=switch&filename=gdbserver-6.8-002-20090131.exe&a=88862589 To me the underlying bug appears obscure. Apparenly, it happens when the sigc++ objects for the address book are destroyed. Can anyone suggest a strategy how to approach this crash? This is a bug which appears on gnu/linux too and which gives headaches to snark :o) Please be patient (http://bugzilla.gnome.org/show_bug.cgi?id=570008). -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 issues
Eugen Dedu a écrit : Michael Rickmann wrote: Ok I have submitted the two bug reports https://sourceforge.net/tracker/?func=detail&aid=2728003&group_id=204472&atid=989748 https://sourceforge.net/tracker/?func=detail&aid=2728037&group_id=204472&atid=989748 Another Win32 issue, the "crash on exit" one: I have been fighting to obtain a debug built of ekiga which allows gdb to backtrace across different dlls. For others who try the same: in the win32 Makefile autogen.sh with --enable-opal-debug instead of --enable-debug and use -gstabs instead of -g as the debugging flag. Attached gdb backtrace was produced on an XP home machine using the gdb contained in https://sourceforge.net/project/downloading.php?group_id=204414&use_mirror=switch&filename=gdbserver-6.8-002-20090131.exe&a=88862589 To me the underlying bug appears obscure. Apparenly, it happens when the sigc++ objects for the address book are destroyed. Can anyone suggest a strategy how to approach this crash? This is a bug which appears on gnu/linux too and which gives headaches to snark :o) Please be patient (http://bugzilla.gnome.org/show_bug.cgi?id=570008). Oh, yes, I know that bug... but I still haven't understood it... and the fact that I can't reproduce it doesn't help (I get other crashes... in ptlib/opal). Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julien Puydt a écrit : > Julien Puydt a écrit : >> Oh, yes, I know that bug... but I still haven't understood it... and >> the fact that I can't reproduce it doesn't help (I get other >> crashes... in ptlib/opal). > > I got an idea and pushed a would-be fix... but since I can't reproduce > that particular crash, then I'm waiting for feedback to confirm. > > And I'll need to review the code to find out if there are more > occurrences of this situation. > Well, there is a pool of people having this crash with ubuntu, those users are using the dev version of ubuntu, if you provide me a patch for the 3.2.0 source, we could probably build a package using the Ubuntu PPA service and ask those people to try the resulting package. > Snark > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknV/O4ACgkQaP9jcuuuScDHJgCfeUjhwXmRUlIGlrdG4bc6x+Zc 4AUAoIVa6MiG2MUZQScUnouh+pDeknCk =5Oby -END PGP SIGNATURE- ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 issues
Julien Puydt a écrit : Oh, yes, I know that bug... but I still haven't understood it... and the fact that I can't reproduce it doesn't help (I get other crashes... in ptlib/opal). I got an idea and pushed a would-be fix... but since I can't reproduce that particular crash, then I'm waiting for feedback to confirm. And I'll need to review the code to find out if there are more occurrences of this situation. Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 issues
yannick a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julien Puydt a écrit : Julien Puydt a écrit : Oh, yes, I know that bug... but I still haven't understood it... and the fact that I can't reproduce it doesn't help (I get other crashes... in ptlib/opal). I got an idea and pushed a would-be fix... but since I can't reproduce that particular crash, then I'm waiting for feedback to confirm. And I'll need to review the code to find out if there are more occurrences of this situation. Well, there is a pool of people having this crash with ubuntu, those users are using the dev version of ubuntu, if you provide me a patch for the 3.2.0 source, we could probably build a package using the Ubuntu PPA service and ask those people to try the resulting package. I pushed it in trunk... and I haven't put in trunk anything I don't intend to push into stable (I'll still check before pushing though). Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 Ekiga painful
Building Win32 Ekiga from current heads is not straightforward. Ekiga,
Ptlib and Opal seem to have regressed in some aspects.
1) In Ekiga videooutput-manager-dx.cpp can not be compiled. I tried to
fix it with attached patch. There were two major issues: Where does
GMVideoDisplay_DX come from? I guess GMVideoOutputManager_dx was ment.
My compiler wants the functions at the end, like device_error_in_main,
be explicitly made members of class GMVideoOutputManager_dx. Otherwise
it would not allow the signals to be inherited.
2) Ekiga with current Ptlib head is unable to detect any audio or video
devices - all silence. This seems to be due to the changes introduced
with "Replaced PWLibStupidLinkerHacks". I had to go back to revision
22442.
3) Opal was also changed because of the "PWLibStupidLinkerHacks" and
depends on the changes in Ptlib. I had also to go back.
Regards
Michael
diff -ur ekiga.orig/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp ekiga/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp
--- ekiga.orig/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp 2009-04-24 21:31:18.654979488 +0200
+++ ekiga/lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp 2009-04-24 21:33:13.205008765 +0200
@@ -92,14 +92,14 @@
break;
case Ekiga::VO_MODE_UNSET:
default:
-PTRACE (1, "GMVideoOutputManager_DX\tDisplay variable not set");
+PTRACE (1, "GMVideoOutputManager_dx\tDisplay variable not set");
return;
break;
}
if ( (!local_display_info.widget_info_set) || (!local_display_info.config_info_set)
|| (local_display_info.mode == Ekiga::VO_MODE_UNSET) || (local_display_info.zoom == 0) || (current_frame.zoom == 0)) {
-PTRACE(4, "GMVideoOutputManager_DX\tWidget not yet realized or gconf info not yet set, not opening display");
+PTRACE(4, "GMVideoOutputManager_dx\tWidget not yet realized or gconf info not yet set, not opening display");
return;
}
@@ -109,7 +109,7 @@
switch (current_frame.mode) {
case Ekiga::VO_MODE_LOCAL:
-PTRACE(4, "GMVideoOutputManager_DX\tOpening :VO_MODE_LOCAL display with image of " << current_frame.local_width << "x" << current_frame.local_height);
+PTRACE(4, "GMVideoOutputManager_dx\tOpening :VO_MODE_LOCAL display with image of " << current_frame.local_width << "x" << current_frame.local_height);
dxWindow = new DXWindow();
video_disabled = !dxWindow->Init (local_display_info.hwnd,
local_display_info.x,
@@ -129,7 +129,7 @@
break;
case Ekiga::VO_MODE_REMOTE:
-PTRACE(4, "GMVideoOutputManager_DX\tOpening VO_MODE_REMOTE display with image of " << current_frame.remote_width << "x" << current_frame.remote_height);
+PTRACE(4, "GMVideoOutputManager_dx\tOpening VO_MODE_REMOTE display with image of " << current_frame.remote_width << "x" << current_frame.remote_height);
dxWindow = new DXWindow();
video_disabled = !dxWindow->Init (local_display_info.hwnd,
local_display_info.x,
@@ -151,7 +151,7 @@
case Ekiga::VO_MODE_FULLSCREEN:
case Ekiga::VO_MODE_PIP:
case Ekiga::VO_MODE_PIP_WINDOW:
-PTRACE(4, "GMVideoOutputManager_DX\tOpening display " << current_frame.mode << " with images of "
+PTRACE(4, "GMVideoOutputManager_dx\tOpening display " << current_frame.mode << " with images of "
<< current_frame.local_width << "x" << current_frame.local_height << "(local) and "
<< current_frame.remote_width << "x" << current_frame.remote_height << "(remote)");
dxWindow = new DXWindow();
@@ -184,7 +184,7 @@
return;
break;
}
- PTRACE (4, "GMVideoDisplay_DX\tSetup display " << current_frame.mode << " with zoom value of " << current_frame.zoom );
+ PTRACE (4, "GMVideoOutputManager_dx\tSetup display " << current_frame.mode << " with zoom value of " << current_frame.zoom );
if (local_display_info.on_top && dxWindow)
dxWindow->ToggleOntop ();
@@ -197,11 +197,11 @@
if (video_disabled) {
delete dxWindow;
dxWindow = NULL;
-Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, &GMVideoDisplay_DX::device_error_in_main), Ekiga::VO_ERROR));
+Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, &GMVideoOutputManager_dx::device_error_in_main), Ekiga::VO_ERROR));
}
else {
current_frame.accel = Ekiga::VO_ACCEL_ALL;
-Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, &GMVideoDisplay_DX::device_opened_in_main), current_frame.accel, current_frame.mode, current_frame.zoom, current_frame.both_streams_active));
+Ekiga::Runtime::run_in_main (sigc::bind (sigc::mem_fun (this, &GMVideoOutputManager_dx::device_opened_in_main), current_frame.accel, current_frame.mode, current_frame.zoom, current_frame.both_streams_active));
}
}
@@ -261,14 +261,14 @@
}
void
-size_changed_in_main (unsigned width,
+GMVideoOutputManager_dx::size_changed_in_main (unsigned width,
un
Re: [Ekiga-devel-list] Win32 DirectX
Michael Rickmann wrote: Ekiga SVN commit 7653 seems not complete. It is apparently based on a discussion on this list in February: http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00042.html . At the moment I work with Ubuntu Intrepid on git master and get circular inclusion of uuids.h and ksuuids.h which will make the ptlib configure fail for DirectX. Attached diff corrects this. An alternative to tweaking DirectX headers may be to use them as they are ment to be used, i.e. preincluding mingw_dshow_port.h, and change ptlib.m4 accordingly. Is your patch to be included in branch too? Because 7653 was not committed to branch (it seems). -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 DirectX
Michael Rickmann a écrit : Ekiga SVN commit 7653 seems not complete. It is apparently based on a discussion on this list in February: http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00042.html . At the moment I work with Ubuntu Intrepid on git master and get circular inclusion of uuids.h and ksuuids.h which will make the ptlib configure fail for DirectX. Attached diff corrects this. An alternative to tweaking DirectX headers may be to use them as they are ment to be used, i.e. preincluding mingw_dshow_port.h, and change ptlib.m4 accordingly. I pushed your patch in. Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 DirectX
Am Sonntag, den 26.04.2009, 15:31 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Ekiga SVN commit 7653 seems not complete. It is apparently based on a > > discussion on this list in February: > > http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00042.html > > . At the moment I work with Ubuntu Intrepid on git master and get circular > > inclusion of uuids.h and ksuuids.h which will make the ptlib configure fail > > for DirectX. Attached diff corrects this. An alternative to tweaking > > DirectX headers may be to use them as they are ment to be used, i.e. > > preincluding mingw_dshow_port.h, and change ptlib.m4 accordingly. > > Is your patch to be included in branch too? Because 7653 was not > committed to branch (it seems). > I am not familiar with these branches. When I use the git repository browser for gnome-2-26 I can find the entry 2009-02-11 Fixed mingw32 ... . And also the circular dependency inclusion. So the branch needs fixing too I think. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 DirectX
Michael Rickmann wrote: Am Sonntag, den 26.04.2009, 15:31 +0200 schrieb Eugen Dedu: Michael Rickmann wrote: Ekiga SVN commit 7653 seems not complete. It is apparently based on a discussion on this list in February: http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00042.html . At the moment I work with Ubuntu Intrepid on git master and get circular inclusion of uuids.h and ksuuids.h which will make the ptlib configure fail for DirectX. Attached diff corrects this. An alternative to tweaking DirectX headers may be to use them as they are ment to be used, i.e. preincluding mingw_dshow_port.h, and change ptlib.m4 accordingly. Is your patch to be included in branch too? Because 7653 was not committed to branch (it seems). I am not familiar with these branches. When I use the git repository browser for gnome-2-26 I can find the entry 2009-02-11 Fixed mingw32 ... . And also the circular dependency inclusion. So the branch needs fixing too I think. Searching through the web interface of git.gnome.org searches through all the branches. The entry you found is the entry for trunk. Let's just wait a bit, we will need anyway to apply many other fixes from trunk to branch... -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 DirectX
Am Sonntag, den 26.04.2009, 17:00 +0200 schrieb Eugen Dedu: > Michael Rickmann wrote: > > Am Sonntag, den 26.04.2009, 15:31 +0200 schrieb Eugen Dedu: > >> Michael Rickmann wrote: > >>> Ekiga SVN commit 7653 seems not complete. It is apparently based on a > >>> discussion on this list in February: > >>> http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00042.html > >>> . At the moment I work with Ubuntu Intrepid on git master and get > >>> circular inclusion of uuids.h and ksuuids.h which will make the ptlib > >>> configure fail for DirectX. Attached diff corrects this. An alternative > >>> to tweaking DirectX headers may be to use them as they are ment to be > >>> used, i.e. preincluding mingw_dshow_port.h, and change ptlib.m4 > >>> accordingly. > >> Is your patch to be included in branch too? Because 7653 was not > >> committed to branch (it seems). > >> > > I am not familiar with these branches. When I use the git repository > > browser for gnome-2-26 I can find the entry 2009-02-11 Fixed > > mingw32 ... . And also the circular dependency inclusion. So the branch > > needs fixing too I think. > > Searching through the web interface of git.gnome.org searches through > all the branches. The entry you found is the entry for trunk. > > Let's just wait a bit, we will need anyway to apply many other fixes > from trunk to branch... > I can find the culprit in http://svn.gnome.org/viewvc/ekiga/branches/gnome-2-26/win32/directx/ksuuids.h?r1=6838&r2=7653 too. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 DirectX
Michael Rickmann wrote: Am Sonntag, den 26.04.2009, 17:00 +0200 schrieb Eugen Dedu: Michael Rickmann wrote: Am Sonntag, den 26.04.2009, 15:31 +0200 schrieb Eugen Dedu: Michael Rickmann wrote: Ekiga SVN commit 7653 seems not complete. It is apparently based on a discussion on this list in February: http://mail.gnome.org/archives/ekiga-devel-list/2009-February/msg00042.html . At the moment I work with Ubuntu Intrepid on git master and get circular inclusion of uuids.h and ksuuids.h which will make the ptlib configure fail for DirectX. Attached diff corrects this. An alternative to tweaking DirectX headers may be to use them as they are ment to be used, i.e. preincluding mingw_dshow_port.h, and change ptlib.m4 accordingly. Is your patch to be included in branch too? Because 7653 was not committed to branch (it seems). I am not familiar with these branches. When I use the git repository browser for gnome-2-26 I can find the entry 2009-02-11 Fixed mingw32 ... . And also the circular dependency inclusion. So the branch needs fixing too I think. Searching through the web interface of git.gnome.org searches through all the branches. The entry you found is the entry for trunk. Let's just wait a bit, we will need anyway to apply many other fixes from trunk to branch... I can find the culprit in http://svn.gnome.org/viewvc/ekiga/branches/gnome-2-26/win32/directx/ksuuids.h?r1=6838&r2=7653 too. Sorry, my fault. 7653 was committed only to trunk (in Feb), but gnome-2-26 branch was created *after* that date (in March). -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 please test
Hello everybody, I have a new Windows version of Ekiga head based on attached minimal but rather effective patches. you find it in my directory at http://wwwuser.gwdg.de/~mrickma/ekiga/ . As to the patches: 1) ekiga_linkmagic.diff : It allows the linker to chose WinMain as the entry point. Result is that the C-library is initialized properly and Ekiga exits gracefully, at least on XP. Additionally Ekiga can be compiled with the -mwindows flag as Michael Cronenworth suggested. 2) The option to start Ekiga on login which was given in the installer resulted in a non responsive icon in the Windows system tray. You could just quit or ask for help. Ekiga has its own option to start minimized which works very well under Windows. Please test whether the new attempt works for you. I would like to know whether Ekiga really shuts down on Vista or whether it has to be killed with the task manager. Regards Michael diff -ur src/ekiga/src/gui/main.cpp ekiga/src/gui/main.cpp --- src/ekiga/src/gui/main.cpp 2009-06-10 17:46:41.362449431 +0200 +++ ekiga/src/gui/main.cpp 2009-06-10 17:48:20.142449909 +0200 @@ -4329,6 +4329,10 @@ return gtk_image_get_pixbuf (GTK_IMAGE (mw->priv->main_video_image)); } +#ifdef WIN32 +// linker magic +#define main(c,v,e) ekigas_real_main(c,v,e) +#endif /* The main () */ int diff -ur src/ekiga/win32/nsisinstaller/ekiga.nsi ekiga/win32/nsisinstaller/ekiga.nsi --- src/ekiga/win32/nsisinstaller/ekiga.nsi 2009-04-19 18:08:42.860313875 +0200 +++ ekiga/win32/nsisinstaller/ekiga.nsi 2009-06-11 13:58:35.729786000 +0200 @@ -393,7 +393,7 @@ Section $(EKIGA_RUN_AT_STARTUP) SecStartup SetOutPath $INSTDIR - CreateShortCut "$SMSTARTUP\Ekiga.lnk" "$INSTDIR\ekiga.exe" "" "" 0 SW_SHOWMINIMIZED + CreateShortCut "$SMSTARTUP\Ekiga.lnk" "$INSTDIR\ekiga.exe" "" "" 0 SW_SHOWNORMAL SectionEnd SubSectionEnd ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] WIN32 master crashes
I just gave Ekiga master a try with yesterday's Ptlib and Opal. Result is Ekiga does not start up any longer. 1) I get a crash from opal/src/sip/handlers.cxx:1656 m_byAOR.erase(handler->m_byAOR); - backtrace and d4 log are attached. Ok, then I went back to Ekiga d6ff5f8bfcacbb4db 2009-09-04 plus "Cope with opal's recent changes 2009-09-20" with the new Opal and Ptlib (). 2) Then I got an assertion error from ptlib/src/ptlib/common/safecoll.cxx:81 when starting Ekiga without debugger. When running under gdb I get the error described in 1). This indicates that 1) is caused by a heap problem as Windows uses special heap checking when a program is started from a debugger. Michael crash-011009.tar.gz Description: GNU Zip compressed data ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [Win32] boost-exceptions.cpp
There is a trouble with ekiga/lib/engine/framework/boost-exceptions.cpp when cross compiling with mingw32 : abort is undefined. ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [WIN32] loudmouth
Le 11/10/2010 15:53, Thierry Simonnet a écrit : I tested --enable-loudmouth configure option with loudmouth 1.4.3 for windows. That is good news. Result : That looks like not very good news ;-) ../../plugins/loudmouth/loudmouth-presentity.h:70: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-presentity.h:72: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-presentity.h:75: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-presentity.h:82: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-presentity.h:83: error: ISO C++ forbids declaration of âLmMessageNodeâ with no type ../../plugins/loudmouth/loudmouth-heap.h:53: error: âLmConnectionâ has not been declared ../../plugins/loudmouth/loudmouth-heap.h:72: error: âLmHandlerResultâ does not name a type ../../plugins/loudmouth/loudmouth-heap.h:74: error: âLmHandlerResultâ does not name a type ../../plugins/loudmouth/loudmouth-heap.h:76: error: âLmHandlerResultâ does not name a type ../../plugins/loudmouth/loudmouth-heap.h:86: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-heap.h:88: error: ISO C++ forbids declaration of âLmMessageHandlerâ with no type ../../plugins/loudmouth/loudmouth-heap.h:90: error: ISO C++ forbids declaration of âLmMessageHandlerâ with no type ../../plugins/loudmouth/loudmouth-heap.h:92: error: ISO C++ forbids declaration of âLmMessageHandlerâ with no type ../../plugins/loudmouth/loudmouth-heap.h:94: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-account.h:79: error: âLmDisconnectReasonâ has not been declared ../../plugins/loudmouth/loudmouth-account.h:98: error: ISO C++ forbids declaration of âLmConnectionâ with no type I find it disturbing -- the problem is that many things are undefined... but there is no error message indicating the loudmouth headers haven't been found! Could you check your config.log to see : 1. if 2. and where your loudmouth headers have been found? Thanks, Snark PS: I routinely compile that code in... so I know for sure it works ;-) ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [WIN32] loudmouth
Le 11/10/2010 21:10, Julien Puydt a écrit : Le 11/10/2010 15:53, Thierry Simonnet a écrit : I tested --enable-loudmouth configure option with loudmouth 1.4.3 for windows. That is good news. Result : That looks like not very good news ;-) ../../plugins/loudmouth/loudmouth-presentity.h:70: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-presentity.h:72: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-presentity.h:75: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-presentity.h:82: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-presentity.h:83: error: ISO C++ forbids declaration of âLmMessageNodeâ with no type ../../plugins/loudmouth/loudmouth-heap.h:53: error: âLmConnectionâ has not been declared ../../plugins/loudmouth/loudmouth-heap.h:72: error: âLmHandlerResultâ does not name a type ../../plugins/loudmouth/loudmouth-heap.h:74: error: âLmHandlerResultâ does not name a type ../../plugins/loudmouth/loudmouth-heap.h:76: error: âLmHandlerResultâ does not name a type ../../plugins/loudmouth/loudmouth-heap.h:86: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-heap.h:88: error: ISO C++ forbids declaration of âLmMessageHandlerâ with no type ../../plugins/loudmouth/loudmouth-heap.h:90: error: ISO C++ forbids declaration of âLmMessageHandlerâ with no type ../../plugins/loudmouth/loudmouth-heap.h:92: error: ISO C++ forbids declaration of âLmMessageHandlerâ with no type ../../plugins/loudmouth/loudmouth-heap.h:94: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-account.h:79: error: âLmDisconnectReasonâ has not been declared ../../plugins/loudmouth/loudmouth-account.h:98: error: ISO C++ forbids declaration of âLmConnectionâ with no type I find it disturbing -- the problem is that many things are undefined... but there is no error message indicating the loudmouth headers haven't been found! Could you check your config.log to see : 1. if 2. and where I need to force LOUDMOUTH_CFLAGS (-I$(BUILDROOT)/include) and LOUDMOUTH_LIBS ($(BUILDROOT)/loudmouth-1.4.3/include) no linux loudmouth package is installed. your loudmouth headers have been found? Thanks, Snark PS: I routinely compile that code in... so I know for sure it works ;-) ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [WIN32] loudmouth
I re-checked all. It compileswith : LOUDMOUTH_CFLAGS (-I$(BUILDROOT)/include) and LOUDMOUTH_LIBS ($(BUILDROOT)/loudmouth-1.4.3/lib) I made an error when typing path of lib. Le 12/10/2010 08:27, Thierry Simonnet a écrit : Le 11/10/2010 21:10, Julien Puydt a écrit : Le 11/10/2010 15:53, Thierry Simonnet a écrit : I tested --enable-loudmouth configure option with loudmouth 1.4.3 for windows. That is good news. Result : That looks like not very good news ;-) ../../plugins/loudmouth/loudmouth-presentity.h:70: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-presentity.h:72: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-presentity.h:75: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-presentity.h:82: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-presentity.h:83: error: ISO C++ forbids declaration of âLmMessageNodeâ with no type ../../plugins/loudmouth/loudmouth-heap.h:53: error: âLmConnectionâ has not been declared ../../plugins/loudmouth/loudmouth-heap.h:72: error: âLmHandlerResultâ does not name a type ../../plugins/loudmouth/loudmouth-heap.h:74: error: âLmHandlerResultâ does not name a type ../../plugins/loudmouth/loudmouth-heap.h:76: error: âLmHandlerResultâ does not name a type ../../plugins/loudmouth/loudmouth-heap.h:86: error: ISO C++ forbids declaration of âLmConnectionâ with no type ../../plugins/loudmouth/loudmouth-heap.h:88: error: ISO C++ forbids declaration of âLmMessageHandlerâ with no type ../../plugins/loudmouth/loudmouth-heap.h:90: error: ISO C++ forbids declaration of âLmMessageHandlerâ with no type ../../plugins/loudmouth/loudmouth-heap.h:92: error: ISO C++ forbids declaration of âLmMessageHandlerâ with no type ../../plugins/loudmouth/loudmouth-heap.h:94: error: âLmMessageNodeâ has not been declared ../../plugins/loudmouth/loudmouth-account.h:79: error: âLmDisconnectReasonâ has not been declared ../../plugins/loudmouth/loudmouth-account.h:98: error: ISO C++ forbids declaration of âLmConnectionâ with no type I find it disturbing -- the problem is that many things are undefined... but there is no error message indicating the loudmouth headers haven't been found! Could you check your config.log to see : 1. if 2. and where I need to force LOUDMOUTH_CFLAGS (-I$(BUILDROOT)/include) and LOUDMOUTH_LIBS ($(BUILDROOT)/loudmouth-1.4.3/include) no linux loudmouth package is installed. your loudmouth headers have been found? Thanks, Snark PS: I routinely compile that code in... so I know for sure it works ;-) ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [WIN32] loudmouth
Le 12/10/2010 09:07, Thierry Simonnet a écrit : I re-checked all. It compileswith : LOUDMOUTH_CFLAGS (-I$(BUILDROOT)/include) and LOUDMOUTH_LIBS ($(BUILDROOT)/loudmouth-1.4.3/lib) I made an error when typing path of lib. Good! Now that it compiles, does the plugin load, and does it run? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [WIN32] loudmouth
I will test this afternoon. The trouble is opal trunk. It crashes (even under Linux). I try to diagnose the trouble. On 10/12/2010 09:19 AM, Julien Puydt wrote: Le 12/10/2010 09:07, Thierry Simonnet a écrit : I re-checked all. It compileswith : LOUDMOUTH_CFLAGS (-I$(BUILDROOT)/include) and LOUDMOUTH_LIBS ($(BUILDROOT)/loudmouth-1.4.3/lib) I made an error when typing path of lib. Good! Now that it compiles, does the plugin load, and does it run? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- Thierry Simonnet ESIEE-Paris Par respect pour l’environnement, n’imprimez ce mail que si nécessaire ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [WIN32] loudmouth
I will test this afernoon. Package is available at : http://www.pateam.org/archive/tmp/ekiga-win32/trunk/ekiga-setup-3.3.0-git-751_g28e8bfe.exe First tests : no contact tab, not sending video. Let me know if you have something to check loudmouth. On 10/12/2010 09:19 AM, Julien Puydt wrote: Le 12/10/2010 09:07, Thierry Simonnet a écrit : I re-checked all. It compileswith : LOUDMOUTH_CFLAGS (-I$(BUILDROOT)/include) and LOUDMOUTH_LIBS ($(BUILDROOT)/loudmouth-1.4.3/lib) I made an error when typing path of lib. Good! Now that it compiles, does the plugin load, and does it run? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- Thierry Simonnet ESIEE-Paris Par respect pour l’environnement, n’imprimez ce mail que si nécessaire ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [WIN32] loudmouth
Le 12/10/2010 09:24, Thierry Simonnet a écrit : The trouble is opal trunk. It crashes (even under Linux). Eh. We track ptlib+opal stable, so it's no wonder! Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [WIN32] loudmouth
Le 12/10/2010 09:43, Thierry Simonnet a écrit : Let me know if you have something to check loudmouth. You just need a jabber account somewhere... connect to it and see your contacts appear. Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [WIN32] loudmouth
I work on x264 and need trunk version for my projects. I will remote control a robot using IM facilities. Then H.264 codec. I saw that IM is not well set on ekiga. Some informations like identity (To, From, channel...) needs to be checked. The aim is to send IM through a established communication. This implies multiple PBX. As I can see, ekiga IM works only as p2p. Le 12/10/2010 10:13, Julien Puydt a écrit : Le 12/10/2010 09:24, Thierry Simonnet a écrit : The trouble is opal trunk. It crashes (even under Linux). Eh. We track ptlib+opal stable, so it's no wonder! Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [win32] git version
Hello, there is something odd in ekiga/src/gui/call_window.cpp line 2618 call_panel_frame is undefined (not used for Linux version) For pixmap : when cross-compiling ekiga for windows, I don't need to have Gnome and then I don't have gnome icons. Then pixmaps/256x256/avatar-default is missing. Best regards Thierry -- Thierry Simonnet ESIEE-Paris Par respect pour l’environnement, n’imprimez ce mail que si nécessaire ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [win32] new GUI
Hello, new GUI with buttons is convenient. No more trouble with numbers, but... ;-) H323 is not working as usual. I have to investigate I think that audio and video codecs should be displayed like performance parameters. Useful to check codec negociation. new png icons for new GUI are not well set up and are not present in win32 version Best regards -- Thierry Simonnet ESIEE-Paris Par respect pour l’environnement, n’imprimez ce mail que si nécessaire ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [Win32] Last modifications
Hello, I applied the last modifications from git. I have the following messages : /win32/include/ptlib/pstring.h:1651:46: warning: declaration of 'reference' shadows a member of 'this' [-Wshadow] In file included from /root/win32/include/ptlib/contain.h:624:0, from /root/win32/include/ptlib.h:56, from ../lib/engine/components/common-videooutput/videooutput-manager-common.h:51, from ../lib/engine/components/dx-videooutput/videooutput-manager-dx.h:44, from ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:38: /win32/include/ptlib/pstring.h: In constructor 'PWideString::PWideString(PContainerReference&)': /win32/include/ptlib/pstring.h:1686:52: warning: declaration of 'reference' shadows a member of 'this' [-Wshadow] /win32/include/ptlib/pstring.h: In constructor 'PCaselessString::PCaselessString(PContainerReference&)': /win32/include/ptlib/pstring.h:1814:54: warning: declaration of 'reference' shadows a member of 'this' [-Wshadow] ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp: In member function 'virtual void GMVideoOutputManager_dx::setup_frame_display()': ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:89:12: error: 'Ekiga::Runtime' has not been declared ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:97:12: error: 'Ekiga::Runtime' has not been declared ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:104:12: error: 'Ekiga::Runtime' has not been declared ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:109:12: error: 'Ekiga::Runtime' has not been declared ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:114:12: error: 'Ekiga::Runtime' has not been declared ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:250:12: error: 'Ekiga::Runtime' has not been declared ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:254:12: error: 'Ekiga::Runtime' has not been declared ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp: In member function 'virtual void GMVideoOutputManager_dx::close_frame_display()': ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:265:10: error: 'Ekiga::Runtime' has not been declared ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp: In member function 'virtual void GMVideoOutputManager_dx::display_pip_frames(const char*, unsigned int, unsigned int, const char*, unsigned int, unsigned int)': ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:297:12: error: 'Ekiga::Runtime' has not been declared ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp: At global scope: ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:311:1: warning: unused parameter 'sync_required' [-Wunused-parameter] In file included from /root/win32/include/ptlib/contain.h:608:0, from /root/win32/include/ptlib.h:56, from ../lib/engine/components/common-videooutput/videooutput-manager-common.h:51, from ../lib/engine/components/dx-videooutput/videooutput-manager-dx.h:44, from ../lib/engine/components/dx-videooutput/videooutput-manager-dx.cpp:38: /win32/include/ptlib/array.h: In constructor 'PBaseArray::PBaseArray(PContainerReference&) [with T = char]': /win32/include/ptlib/array.h:571:1: instantiated from here /win32/include/ptlib/array.h:449:5: warning: declaration of 'reference' shadows a member of 'this' [-Wshadow] /win32/include/ptlib/array.h: In constructor 'PBaseArray::PBaseArray(PContainerReference&) [with T = unsigned char]': /win32/include/ptlib/array.h:691:1: instantiated from here /win32/include/ptlib/array.h:449:5: warning: declaration of 'reference' shadows a member of 'this' [-Wshadow] /win32/include/ptlib/array.h: In constructor 'PBaseArray::PBaseArray(PContainerReference&) [with T = PHashTableElement*]': /win32/include/ptlib/dict.h:150:1: instantiated from here /win32/include/ptlib/array.h:449:5: warning: declaration of 'reference' shadows a member of 'this' [-Wshadow] /win32/include/ptlib/array.h: In constructor 'PBaseArray::PBaseArray(PContainerReference&) [with T = wchar_t]': /win32/include/ptlib/pstring.h:1686:75: instantiated from here /win32/include/ptlib/array.h:449:5: warning: declaration of 'reference' shadows a member of 'this' [-Wshadow] make[3]: *** [videooutput-manager-dx.lo] Error 1 make[3]: Leaving directory `/win32/ekiga/lib' make[2]: *** [install] Error 2 make[2]: Leaving directory `/win32/ekiga/lib' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/win32/ekiga' make: *** [/win32/dist/zips] Error 2 Best regards -- Thierry Simonnet ESIEE-Paris Par respect pour l’environnement, n’imprimez ce mail que si nécessaire ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] [Win32] gsettings trouble
Hello, I tested the last modifs from git. I have the following errors : /usr/bin/install -c ekiga-config-tool '/win32/dist/Ekiga' make[4]: Leaving directory `/win32/ekiga/src' make[3]: Leaving directory `/win32/ekiga/src' make[2]: Leaving directory `/win32/ekiga/src' Making install in plugins make[2]: Entering directory `/win32/ekiga/plugins' Making install in ldap make[3]: Entering directory `/win32/ekiga/plugins/ldap' CXXLD libgmldap.la *** Warning: Linking the shared library libgmldap.la against the loadable module *** libekiga.dll.a is not portable! .libs/ldap-source.o: In function `ZN5Ekiga8Settings10set_stringERKSsS2_': /win32/ekiga/plugins/ldap/../../lib/settings/ekiga-settings.h:128: undefined reference to `g_settings_set_string' .libs/ldap-source.o: In function `ZN5Ekiga8Settings10get_stringERKSs': /win32/ekiga/plugins/ldap/../../lib/settings/ekiga-settings.h:116: undefined reference to `g_settings_get_string' /win32/ekiga/plugins/ldap/../../lib/settings/ekiga-settings.h:116: undefined reference to `g_settings_get_string' .libs/ldap-source.o: In function `ZN5Ekiga8SettingsC1ERKSs': /win32/ekiga/plugins/ldap/../../lib/settings/ekiga-settings.h:99: undefined reference to `g_settings_new' collect2: error: ld returned 1 exit status make[3]: *** [libgmldap.la] Error 1 make[3]: Leaving directory `/win32/ekiga/plugins/ldap' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/win32/ekiga/plugins' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/win32/ekiga' make: *** [/win32/dist/zips] Error 2 austerlitz:~/win32# -- Thierry Simonnet ESIEE-Paris Par respect pour l’environnement, n’imprimez ce mail que si nécessaire ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 build broken?
Le lundi 10 mars 2008 à 15:52 +0100, Torsten Schlabach a écrit : > Dear list! > > I am currently trying this: > > http://wiki.ekiga.org/index.php/Cross-compile_Win32 > > but fail: > > # make > make -j1 -C /usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib > make[1]: Entering directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' > make all-am > make[2]: Entering directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' > make[2]: *** No rule to make target `src/ptclib/url.cxx', needed by `url.lo'. > Stop. > make[2]: Leaving directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' > make: *** [/usr/local/src/ekiga-win32/ekiga-win32-cross/lib/libpt.a] Error 2 > > Is that anything obvious or should I work with the PTLib developers on that? > They won't help with that, as it is a problem of cross-compilation. It seems to be indeed broken. You will have to fight with the Makefile to fix it or wait that somebody does it. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 build broken?
> as it is a problem of cross-compilation. How can we be sure about that? Regards, Torsten Original-Nachricht > Datum: Mon, 10 Mar 2008 15:57:09 +0100 > Von: Damien Sandras <[EMAIL PROTECTED]> > An: Ekiga development mailing list > Betreff: Re: [Ekiga-devel-list] Win32 build broken? > > Le lundi 10 mars 2008 à 15:52 +0100, Torsten Schlabach a écrit : > > Dear list! > > > > I am currently trying this: > > > > http://wiki.ekiga.org/index.php/Cross-compile_Win32 > > > > but fail: > > > > # make > > make -j1 -C /usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib > > make[1]: Entering directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' > > make all-am > > make[2]: Entering directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' > > make[2]: *** No rule to make target `src/ptclib/url.cxx', needed by > `url.lo'. Stop. > > make[2]: Leaving directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross/ptlib' > > make: *** [/usr/local/src/ekiga-win32/ekiga-win32-cross/lib/libpt.a] > Error 2 > > > > Is that anything obvious or should I work with the PTLib developers on > that? > > > > They won't help with that, as it is a problem of cross-compilation. > > It seems to be indeed broken. You will have to fight with the Makefile > to fix it or wait that somebody does it. > -- > _ Damien Sandras > (o- > //\Ekiga Softphone : http://www.ekiga.org/ > v_/_ NOVACOM : http://www.novacom.be/ >FOSDEM : http://www.fosdem.org/ >SIP Phone : sip:[EMAIL PROTECTED] > > > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 build broken?
Ok, I was able to get over that: # diff ptlib/Makefile.original ptlib/Makefile 305c305 < am__objects_32 = url.lo --- > #am__objects_32 = url.lo The source file url.cxx seems to have disappeared / been renamed. After commenting out that one line, I can successfully cross-compile ptlib. I seem go have an issue when it comes to installing: install: missing destination file operand after `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avutil-49.5.0.dll' In context: make -C libavutil install-libs make[2]: Entering directory `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/ffmpeg/libavutil' install -d "/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin" install -m 755 "/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avutil-49.5.0.dll" install: missing destination file operand after `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avutil-49.5.0.dll' Try `install --help' for more information. make[2]: *** [install-lib-shared] Error 1 make[2]: Leaving directory `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/ffmpeg/libavutil' make[1]: *** [install-libs] Error 2 make[1]: Leaving directory `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/ffmpeg' make: *** [/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avcodec.dll] Error 2 Regards, Torsten Original-Nachricht > Datum: Mon, 10 Mar 2008 16:08:50 +0100 > Von: Damien Sandras <[EMAIL PROTECTED]> > An: Ekiga development mailing list > Betreff: Re: [Ekiga-devel-list] Win32 build broken? > > Le lundi 10 mars 2008 à 16:07 +0100, Torsten Schlabach a écrit : > > > as it is a problem of cross-compilation. > > > > How can we be sure about that? > > > > Because the Makefiles are not the same in both cases. > -- > _ Damien Sandras > (o- > //\Ekiga Softphone : http://www.ekiga.org/ > v_/_ NOVACOM : http://www.novacom.be/ >FOSDEM : http://www.fosdem.org/ >SIP Phone : sip:[EMAIL PROTECTED] > > > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 build broken?
Le lundi 10 mars 2008 à 16:07 +0100, Torsten Schlabach a écrit : > > as it is a problem of cross-compilation. > > How can we be sure about that? > Because the Makefiles are not the same in both cases. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 build broken?
Le lundi 10 mars 2008 à 16:41 +0100, Torsten Schlabach a écrit : > Ok, I was able to get over that: > > # diff ptlib/Makefile.original ptlib/Makefile > 305c305 > < am__objects_32 = url.lo > --- > > #am__objects_32 = url.lo > > > The source file url.cxx seems to have disappeared / been renamed. After > commenting out that one line, I can successfully cross-compile ptlib. Is it trunk or 2.0.x ? > I seem go have an issue when it comes to installing: > > install: missing destination file operand after > `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avutil-49.5.0.dll' > > > In context: > > > make -C libavutil install-libs > make[2]: Entering directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/ffmpeg/libavutil' > install -d > "/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin" > install -m 755 > "/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avutil-49.5.0.dll" > install: missing destination file operand after > `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avutil-49.5.0.dll' > Try `install --help' for more information. > make[2]: *** [install-lib-shared] Error 1 > make[2]: Leaving directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/ffmpeg/libavutil' > make[1]: *** [install-libs] Error 2 > make[1]: Leaving directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/ffmpeg' > make: *** > [/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avcodec.dll] > Error 2 > > Not sure about this one. Perhaps Matthias knows. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 build broken?
--- Damien Sandras <[EMAIL PROTECTED]> schrieb: > > Le lundi 10 mars 2008 à 16:41 +0100, Torsten Schlabach a écrit : > > Ok, I was able to get over that: > > > > # diff ptlib/Makefile.original ptlib/Makefile > > 305c305 > > < am__objects_32 = url.lo > > --- > > > #am__objects_32 = url.lo > > > > > > The source file url.cxx seems to have disappeared / been renamed. After > > commenting out that > one line, I can successfully cross-compile ptlib. > > Is it trunk or 2.0.x ? > > > I seem go have an issue when it comes to installing: > > > > install: missing destination file operand after > `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avutil-49.5.0.dll' > > > > > > In context: > > > > > > make -C libavutil install-libs > > make[2]: Entering directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/ffmpeg/libavutil' > > install -d > > "/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin" > > install -m 755 > "/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avutil-49.5.0.dll" > > install: missing destination file operand after > `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avutil-49.5.0.dll' > > Try `install --help' for more information. > > make[2]: *** [install-lib-shared] Error 1 > > make[2]: Leaving directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/ffmpeg/libavutil' > > make[1]: *** [install-libs] Error 2 > > make[1]: Leaving directory > `/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/ffmpeg' > > make: *** > > [/usr/local/src/ekiga-win32/ekiga-win32-cross2/ekiga-win32-cross/bin/avcodec.dll] > Error 2 > > > > > > Not sure about this one. Perhaps Matthias knows. Well, one point is that the source code snapshot packages downloaded by the script are about 4 months old since Kilian does no longer maintain them (i.e. ptlib, opal and ekiga -snapshot). Second point is that even with current sources there is no guarantee that it will work since it has been a while since I last fixed it. The win32 build will be a major post-3.00 point. Matthias Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 build broken?
> --- Damien Sandras <[EMAIL PROTECTED]> schrieb: > Is it trunk or 2.0.x ? I was going to say, it's trunk (as the filename has 'snapshot' in it), but: > Well, one point is that the source code snapshot packages downloaded > by the script are about 4 months old since Kilian does no longer > maintain them (i.e. ptlib, opal and ekiga -snapshot). Ok, how about fixing that ... > Second point is that even with current sources there is no guarantee > that it will work since it has been a while since I last fixed it. The > win32 build will be a major post-3.00 point. We'll know once we try. What I wonder, when you say "Kilian does not longer maintain them", are these snapshot files more than just tared SVN snapshots? Regards, Torsten ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 build broken?
On Monday 10 March 2008 20:53:17 Torsten Schlabach wrote: > > --- Damien Sandras <[EMAIL PROTECTED]> schrieb: > > Is it trunk or 2.0.x ? > > I was going to say, it's trunk (as the filename has 'snapshot' in it), but: trunk=head=snapshot = soon-3.00 > > Well, one point is that the source code snapshot packages downloaded > > by the script are about 4 months old since Kilian does no longer > > maintain them (i.e. ptlib, opal and ekiga -snapshot). > > Ok, how about fixing that ... If you want to do that help is welcome in many areas of ekiga development and support. > > > Second point is that even with current sources there is no guarantee > > that it will work since it has been a while since I last fixed it. The > > win32 build will be a major post-3.00 point. > > We'll know once we try. > > What I wonder, when you say "Kilian does not longer maintain them", are > these snapshot files more than just tared SVN snapshots? No they arent. You can replace these files by your own tarball and make use of the original makefile. > Regards, > Torsten > > ___ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build updated
Hi Matthias! Thanks for your effort. I couldn't wait to try it. Good news first: It worked 99%! It compiled Ekiga, but it failed to create the installer. I will attach a complete log file of the entire build. Some remarks: 1. There is still that automake-1.9 versus 1.20 problem. I had to patch the Makefile. 2. It seems to be important to stick to 1. make update-sources 2. apply the patches to OPAL and PTLib (as long as they are needed) 3. make In an earlier attempt, I was curious if I would get the same error message which you got, so I did not patch, but did a make update-sources, tried a make, which failed, than patched the libs and tried again, but was unable to recover. Tomorrow I will try and run the .exe on a Windows box and report the results. I will just have to check how to get it installed without the installer. Actually, the dist/Eikiga dir seems to have most of what I would probably need, but I cannot spot the OPAL and PTLib DLLs there. Additional questions: - Will we now have a nightly build again? > However, we will probably drop the 2.0 stuff > since it is coming to an end-of-life... Can we please keep it around at least until the first release of 3.0 is available? As long as 3.0 is an entirely moving target, I'd argue that there are people using 2.0.x in production (either on Linux or Windows) and would need to be able to fix bugs. Obviously, the build which lead to 2.0.11-BETA.exe does not seem to be reproduceable until know and AFAIK there is no 2.0.12 for Windows at all. Regards, Torsten Original-Nachricht > Datum: Mon, 07 Apr 2008 08:19:16 +0200 > Von: Matthias Schneider <[EMAIL PROTECTED]> > An: Ekiga development mailing list > Betreff: [Ekiga-devel-list] win32 build updated > > > Hi all, > due to the huge demand of the win32 build I have updated Ekiga's Makefile > to > work with current ptlib, opal and ekiga svn trunk. The only issue > remaining are > the changes made in > > revision 18828: Fixed UNICODE support issue where wchar_t is not precisely > the > same thing as the WORD (aka unsigned short) type previously used in > strings. > > and the corresponding OPAL commit. It completely breaks Ekiga's > cross-compilation with errors like this: > > ./src/ptclib/asner.cxx: In member function 'PBoolean > PASN_BMPString::IsLegalCharacter(WORD)': > ./src/ptclib/asner.cxx:1490: error: invalid conversion from 'const short > unsigned int*' to 'const wchar_t*' > In file included from ./src/ptclib/asner.cxx:2498: > ./src/ptclib/asnber.cxx: In member function 'void > PASN_BMPString::EncodeBER(PBER_Stream&) const': > ./src/ptclib/asnber.cxx:246: error: invalid cast from type 'const > PWCharArray' > to type 'const wchar_t*' > > [...] > > ./src/ptlib/common/contain.cxx: In constructor 'PString::PString(const > PWCharArray&)': > ./src/ptlib/common/contain.cxx:631: error: invalid conversion from 'const > short > unsigned int*' to 'const wchar_t*' > ./src/ptlib/common/contain.cxx:631: error: initializing argument 1 of > 'void > PString::InternalFromUCS2(const wchar_t*, int)' > ./src/ptlib/common/contain.cxx: In member function 'PWCharArray > PString::AsUCS2() const': > ./src/ptlib/common/contain.cxx:1695: error: invalid conversion from 'short > unsigned int*' to 'WCHAR*' > ./src/ptlib/common/contain.cxx:1695: error: initializing argument 5 of > 'int > MultiByteToWideChar(UINT, DWORD, const CHAR*, int, WCHAR*, int)' > > Craig, Robert, I do not know if you are both subscribed to this list, but > if you > are, could you give it a look? > > In case someone wants to build a win32 ekiga he/she can do the following: > - get the buildscript like described on the wiki > - make update-sources > - aplly the enclosed patches to opal and ptlib, which revert the WideChar > commits > - make > > The resulting executable and installer have not been tested by me though, > so no > guarantee it will work... > > I have also updated the wiki, separating 2.0 stuff from 3.0 stuff. > However, we > will probably drop the 2.0 stuff since it is coming to an end-of-life... > > Matthias > > > > > This message was sent using IMP, the Internet Messaging Program. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build updated
Sorry, log attached now. Original-Nachricht > Datum: Mon, 07 Apr 2008 23:26:02 +0200 > Von: "Torsten Schlabach" <[EMAIL PROTECTED]> > An: Ekiga development mailing list , > ekiga-devel-list@gnome.org > Betreff: Re: [Ekiga-devel-list] win32 build updated > Hi Matthias! > > Thanks for your effort. I couldn't wait to try it. > > Good news first: It worked 99%! It compiled Ekiga, but it failed to create > the installer. I will attach a complete log file of the entire build. > > Some remarks: > > 1. There is still that automake-1.9 versus 1.20 problem. I had to patch > the Makefile. > > 2. It seems to be important to stick to > > 1. make update-sources > 2. apply the patches to OPAL and PTLib (as long as they are needed) > 3. make > > In an earlier attempt, I was curious if I would get the same error message > which you got, so I did not patch, but did a make update-sources, tried a > make, which failed, than patched the libs and tried again, but was unable > to recover. > > Tomorrow I will try and run the .exe on a Windows box and report the > results. I will just have to check how to get it installed without the > installer. > > Actually, the dist/Eikiga dir seems to have most of what I would probably > need, but I cannot spot the OPAL and PTLib DLLs there. > > Additional questions: > > - Will we now have a nightly build again? > > > However, we will probably drop the 2.0 stuff > > since it is coming to an end-of-life... > > Can we please keep it around at least until the first release of 3.0 is > available? As long as 3.0 is an entirely moving target, I'd argue that there > are people using 2.0.x in production (either on Linux or Windows) and would > need to be able to fix bugs. > > Obviously, the build which lead to 2.0.11-BETA.exe does not seem to be > reproduceable until know and AFAIK there is no 2.0.12 for Windows at all. > > Regards, > Torsten > > > ---- Original-Nachricht > > Datum: Mon, 07 Apr 2008 08:19:16 +0200 > > Von: Matthias Schneider <[EMAIL PROTECTED]> > > An: Ekiga development mailing list > > Betreff: [Ekiga-devel-list] win32 build updated > > > > > > > Hi all, > > due to the huge demand of the win32 build I have updated Ekiga's > Makefile > > to > > work with current ptlib, opal and ekiga svn trunk. The only issue > > remaining are > > the changes made in > > > > revision 18828: Fixed UNICODE support issue where wchar_t is not > precisely > > the > > same thing as the WORD (aka unsigned short) type previously used in > > strings. > > > > and the corresponding OPAL commit. It completely breaks Ekiga's > > cross-compilation with errors like this: > > > > ./src/ptclib/asner.cxx: In member function 'PBoolean > > PASN_BMPString::IsLegalCharacter(WORD)': > > ./src/ptclib/asner.cxx:1490: error: invalid conversion from 'const short > > unsigned int*' to 'const wchar_t*' > > In file included from ./src/ptclib/asner.cxx:2498: > > ./src/ptclib/asnber.cxx: In member function 'void > > PASN_BMPString::EncodeBER(PBER_Stream&) const': > > ./src/ptclib/asnber.cxx:246: error: invalid cast from type 'const > > PWCharArray' > > to type 'const wchar_t*' > > > > [...] > > > > ./src/ptlib/common/contain.cxx: In constructor 'PString::PString(const > > PWCharArray&)': > > ./src/ptlib/common/contain.cxx:631: error: invalid conversion from > 'const > > short > > unsigned int*' to 'const wchar_t*' > > ./src/ptlib/common/contain.cxx:631: error: initializing argument 1 of > > 'void > > PString::InternalFromUCS2(const wchar_t*, int)' > > ./src/ptlib/common/contain.cxx: In member function 'PWCharArray > > PString::AsUCS2() const': > > ./src/ptlib/common/contain.cxx:1695: error: invalid conversion from > 'short > > unsigned int*' to 'WCHAR*' > > ./src/ptlib/common/contain.cxx:1695: error: initializing argument 5 of > > 'int > > MultiByteToWideChar(UINT, DWORD, const CHAR*, int, WCHAR*, int)' > > > > Craig, Robert, I do not know if you are both subscribed to this list, > but > > if you > > are, could you give it a look? > > > > In case someone wants to build a win32 ekiga he/she can do the > following: > > - get the buildscript like described on the wiki > > - make update-sources > > - aplly the enclosed patches to opal an
Re: [Ekiga-devel-list] win32 build updated
Quoting Torsten Schlabach <[EMAIL PROTECTED]>: > Hi Matthias! > > Thanks for your effort. I couldn't wait to try it. > > Good news first: It worked 99%! It compiled Ekiga, but it failed to create > the installer. I will attach a complete log file of the entire build. > > Some remarks: > > 1. There is still that automake-1.9 versus 1.20 problem. I had to patch the > Makefile. Yes, but just in 1 place and no longer in 4 places. In case you have an idea how to autodetect this, feel free to contribute. > > 2. It seems to be important to stick to > > 1. make update-sources > 2. apply the patches to OPAL and PTLib (as long as they are needed) > 3. make > > In an earlier attempt, I was curious if I would get the same error message > which you got, so I did not patch, but did a make update-sources, tried a > make, which failed, than patched the libs and tried again, but was unable to > recover. In order to work with the windows buildscript, it is important to know the buildprocess. make update-sources only updates the files in the src directory. Then, when you rebuild, of course you only want to rebuild everything that has changed during that last download, and everything depending on it. This should be working for http downloads, and I have figured a hacked support for SVN as well that does a simple touch on the dir if any file was updated. It does not work for git yet. I.e. if SVN is still at the same revision and no other source file has changed, a new make wont do anything. If you do "make" usually the order is like this: - rm -rf the packages dir - copy if from src to buildroot/libname - patch it - configure it - make it - install it i.e. if you want to rebuild ptlib from a scratch, you can delete the buildroot/ptlib dir and rerun make. if you have changed some file in buildroot/ptlib, you can remove the lib/libpt.a file in order to trigger a rebuild if I remeber correctly. Just have a look on how the dependencies are defined. > Tomorrow I will try and run the .exe on a Windows box and report the results. > I will just have to check how to get it installed without the installer. > > Actually, the dist/Eikiga dir seems to have most of what I would probably > need, but I cannot spot the OPAL and PTLib DLLs there. Its statically linked... > > Additional questions: > > - Will we now have a nightly build again? It seems the infrastructure is still up. That means once pptlib and opal build out of the box again, we probably will. If the infrastructure is not up anymore, probably not... > > > However, we will probably drop the 2.0 stuff > > since it is coming to an end-of-life... > > Can we please keep it around at least until the first release of 3.0 is > available? As long as 3.0 is an entirely moving target, I'd argue that there > are people using 2.0.x in production (either on Linux or Windows) and would > need to be able to fix bugs. What do you mean keep it around? I thought its not working anyway? I can only tell you I do not have a single minute I can put into anything related to 2.0.x, actually I had mentally moved the 3.0 windows buidl to 3.2 already... > Obviously, the build which lead to 2.0.11-BETA.exe does not seem to be > reproduceable until know and AFAIK there is no 2.0.12 for Windows at all. > > Regards, > Torsten About the installer, I have no idea right now except that I will compare your nsis version with mine... Matthias > > Original-Nachricht ---- > > Datum: Mon, 07 Apr 2008 08:19:16 +0200 > > Von: Matthias Schneider <[EMAIL PROTECTED]> > > An: Ekiga development mailing list > > Betreff: [Ekiga-devel-list] win32 build updated > > > > > > > Hi all, > > due to the huge demand of the win32 build I have updated Ekiga's Makefile > > to > > work with current ptlib, opal and ekiga svn trunk. The only issue > > remaining are > > the changes made in > > > > revision 18828: Fixed UNICODE support issue where wchar_t is not precisely > > the > > same thing as the WORD (aka unsigned short) type previously used in > > strings. > > > > and the corresponding OPAL commit. It completely breaks Ekiga's > > cross-compilation with errors like this: > > > > ./src/ptclib/asner.cxx: In member function 'PBoolean > > PASN_BMPString::IsLegalCharacter(WORD)': > > ./src/ptclib/asner.cxx:1490: error: invalid conversion from 'const short > > unsigned int*' to 'const wchar_t*' > > In file included from ./src/ptclib/asner.cxx:2498: > > ./src/ptclib/asnber.cxx: In member function 'void > > PASN_BMPString::EncodeBER(PBER_Stream&) const': > > ./src/ptclib/asnber.cxx:246: error: invalid cast from type &
Re: [Ekiga-devel-list] win32 build updated
Good morning! > > 1. There is still that automake-1.9 versus 1.20 problem. I had to patch > > the Makefile. > > Yes, but just in 1 place and no longer in 4 places. In case you have an > idea how to autodetect this, feel free to contribute. Not yet, but I am sure, we will find something. Some gnome config script has the same problem and they haven't solved that yet AFAIK. It's prio #2 for me, right *after* being able to actually run a 3.0 SVN on Windows (see installer issue). > > - Will we now have a nightly build again? > > It seems the infrastructure is still up. That means once pptlib and opal > build out of the box again, we probably will. If the infrastructure is > not up anymore, probably not... I would be able to donate infrastructure if needed. Who owns the current one? [2.0 build] > What do you mean keep it around? I thought its not working anyway? I can > only tell you I do not have a single minute I can put into anything > related to 2.0.x, actually I had mentally moved the 3.0 windows buidl to > 3.2 already... I mean: Keep the Wiki page where it is and accept a fix to the Makefile if I or someone else has one. I am supporting people who use 2.0.11 on Windows right now. They have some issues which I might need to fix or which might be fixed already in 2.0.12. But I cannot move these people to a moving target 3.0 SVN version. Isn't it good practice to keep bugfixing the stable version of an app until the next version is out and usually even running for X amount of time? I can understand that you cannot / don't want to spent time on it, but others might want to. If possible, I'd like to avoid the situation where 2.0 doesn't work and 3.0 isn't there yet. > About the installer, I have no idea right now except that I will compare > your nsis version with mine... Which one do you have? On what distro? Regards, Torsten Original-Nachricht > Datum: Tue, 08 Apr 2008 08:41:36 +0200 > Von: Matthias Schneider <[EMAIL PROTECTED]> > An: Ekiga development mailing list , Torsten > Schlabach <[EMAIL PROTECTED]> > CC: Ekiga development mailing list > Betreff: Re: [Ekiga-devel-list] win32 build updated > Quoting Torsten Schlabach <[EMAIL PROTECTED]>: > > > Hi Matthias! > > > > Thanks for your effort. I couldn't wait to try it. > > > > Good news first: It worked 99%! It compiled Ekiga, but it failed to > create > > the installer. I will attach a complete log file of the entire build. > > > > Some remarks: > > > > 1. There is still that automake-1.9 versus 1.20 problem. I had to patch > the > > Makefile. > Yes, but just in 1 place and no longer in 4 places. In case you have an > idea how > to autodetect this, feel free to contribute. > > > > > 2. It seems to be important to stick to > > > > 1. make update-sources > > 2. apply the patches to OPAL and PTLib (as long as they are needed) > > 3. make > > > > In an earlier attempt, I was curious if I would get the same error > message > > which you got, so I did not patch, but did a make update-sources, tried > a > > make, which failed, than patched the libs and tried again, but was > unable to > > recover. > > In order to work with the windows buildscript, it is important to know the > buildprocess. make update-sources only updates the files in the src > directory. > Then, when you rebuild, of course you only want to rebuild everything that > has > changed during that last download, and everything depending on it. This > should > be working for http downloads, and I have figured a hacked support for SVN > as > well that does a simple touch on the dir if any file was updated. It does > not > work for git yet. > I.e. if SVN is still at the same revision and no other source file has > changed, > a new make wont do anything. > > If you do "make" usually the order is like this: > - rm -rf the packages dir > - copy if from src to buildroot/libname > - patch it > - configure it > - make it > - install it > i.e. if you want to rebuild ptlib from a scratch, you can delete the > buildroot/ptlib dir and rerun make. if you have changed some file in > buildroot/ptlib, you can remove the lib/libpt.a file in order to trigger a > rebuild if I remeber correctly. Just have a look on how the dependencies > are > defined. > > > Tomorrow I will try and run the .exe on a Windows box and report the > results. > > I will just have to check how to get it installed without the installer. > > > > Actually, the dist/Eikiga dir seems to have most of what I would > probably > > need, but I cannot spot the OPAL and PT
Re: [Ekiga-devel-list] win32 build updated
Quoting Torsten Schlabach <[EMAIL PROTECTED]>: > Good morning! > > > > 1. There is still that automake-1.9 versus 1.20 problem. I had to patch > > > the Makefile. > > > > Yes, but just in 1 place and no longer in 4 places. In case you have an > > idea how to autodetect this, feel free to contribute. > > Not yet, but I am sure, we will find something. Some gnome config script has > the same problem and they haven't solved that yet AFAIK. It's prio #2 for me, > right *after* being able to actually run a 3.0 SVN on Windows (see installer > issue). Yes, I concur... > > > - Will we now have a nightly build again? > > > > It seems the infrastructure is still up. That means once pptlib and opal > > build out of the box again, we probably will. If the infrastructure is > > not up anymore, probably not... > > I would be able to donate infrastructure if needed. Who owns the current one? Hm, is it Kilian's? Damien? I can check tonight if it still works... > [2.0 build] > > What do you mean keep it around? I thought its not working anyway? I can > > only tell you I do not have a single minute I can put into anything > > related to 2.0.x, actually I had mentally moved the 3.0 windows buidl to > > 3.2 already... > > I mean: Keep the Wiki page where it is and accept a fix to the Makefile if I > or someone else has one. I am supporting people who use 2.0.11 on Windows > right now. They have some issues which I might need to fix or which might be > fixed already in 2.0.12. But I cannot move these people to a moving target > 3.0 SVN version. > > Isn't it good practice to keep bugfixing the stable version of an app until > the next version is out and usually even running for X amount of time? > > I can understand that you cannot / don't want to spent time on it, but others > might want to. If possible, I'd like to avoid the situation where 2.0 doesn't > work and 3.0 isn't there yet. You are right that this should be the way to go. In case you want to contribute to both 2.x and 3.0 for windows this would be very appreciated. I also did not know that there are people actually using Ekiga for win since it was never officially released... However, like I said before I can give you support only on the 3.0 version. About 3.0, one known issue is that the DirectShow plugin does not seem to be linked correctly anymore since the switch to gcc 4.x. Any hint on that would also be very appreciated (provided ekiga runs at all, which I havent tried for months...) > > About the installer, I have no idea right now except that I will compare > > your nsis version with mine... > > Which one do you have? On what distro? I cannot check before tonight... > Regards, > Torsten Matthias > > Original-Nachricht ---- > > Datum: Tue, 08 Apr 2008 08:41:36 +0200 > > Von: Matthias Schneider <[EMAIL PROTECTED]> > > An: Ekiga development mailing list , Torsten > Schlabach <[EMAIL PROTECTED]> > > CC: Ekiga development mailing list > > Betreff: Re: [Ekiga-devel-list] win32 build updated > > > Quoting Torsten Schlabach <[EMAIL PROTECTED]>: > > > > > Hi Matthias! > > > > > > Thanks for your effort. I couldn't wait to try it. > > > > > > Good news first: It worked 99%! It compiled Ekiga, but it failed to > > create > > > the installer. I will attach a complete log file of the entire build. > > > > > > Some remarks: > > > > > > 1. There is still that automake-1.9 versus 1.20 problem. I had to patch > > the > > > Makefile. > > Yes, but just in 1 place and no longer in 4 places. In case you have an > > idea how > > to autodetect this, feel free to contribute. > > > > > > > > 2. It seems to be important to stick to > > > > > > 1. make update-sources > > > 2. apply the patches to OPAL and PTLib (as long as they are needed) > > > 3. make > > > > > > In an earlier attempt, I was curious if I would get the same error > > message > > > which you got, so I did not patch, but did a make update-sources, tried > > a > > > make, which failed, than patched the libs and tried again, but was > > unable to > > > recover. > > > > In order to work with the windows buildscript, it is important to know the > > buildprocess. make update-sources only updates the files in the src > > directory. > > Then, when you rebuild, of course you only want to rebuild everything that > > has > > changed during that last download, and everything depending on it. This > > s
Re: [Ekiga-devel-list] win32 build updated
Hi Matthias! Regarding the installer: I commented out all lines saying SetBrandingImage in my /usr/share/nsis/Contrib/Modern\ UI/System.nsh file. This got me beyond that Error: no branding image found in chosen UI! Error in macro MUI_HEADERIMAGE_INIT on macroline 27 [...] Error in macro MUI_LANGUAGE on macroline 7 Error in script "/usr/local/src/ekiga-win32/nsisinstaller/ekiga.nsi" on line 107 -- aborting creation process make: *** [/usr/local/src/ekiga-win32/dist/ekiga-setup-2.9.exe] Error 1 The makensis is currently breaking like this: Goto: ekiga_install_files ReadRegStr $R1 HKLM\SOFTWARE\GTK\2.0\Path SetOutPath: "$INSTDIR" SetOverwrite: on File: "ekiga.exe" [compress]Bus error That "Bus error" might be something on my machine. I keep searching. Regards, Torsten Original-Nachricht > Datum: Tue, 08 Apr 2008 10:57:18 +0200 > Von: Matthias Schneider <[EMAIL PROTECTED]> > An: Torsten Schlabach <[EMAIL PROTECTED]> > CC: ekiga-devel-list@gnome.org > Betreff: Re: [Ekiga-devel-list] win32 build updated > Quoting Torsten Schlabach <[EMAIL PROTECTED]>: > > > Good morning! > > > > > > 1. There is still that automake-1.9 versus 1.20 problem. I had to > patch > > > > the Makefile. > > > > > > Yes, but just in 1 place and no longer in 4 places. In case you have > an > > > idea how to autodetect this, feel free to contribute. > > > > Not yet, but I am sure, we will find something. Some gnome config script > has > > the same problem and they haven't solved that yet AFAIK. It's prio #2 > for me, > > right *after* being able to actually run a 3.0 SVN on Windows (see > installer > > issue). > > Yes, I concur... > > > > > - Will we now have a nightly build again? > > > > > > It seems the infrastructure is still up. That means once pptlib and > opal > > > build out of the box again, we probably will. If the infrastructure is > > > not up anymore, probably not... > > > > I would be able to donate infrastructure if needed. Who owns the current > one? > > Hm, is it Kilian's? Damien? I can check tonight if it still works... > > > [2.0 build] > > > What do you mean keep it around? I thought its not working anyway? I > can > > > only tell you I do not have a single minute I can put into anything > > > related to 2.0.x, actually I had mentally moved the 3.0 windows buidl > to > > > 3.2 already... > > > > I mean: Keep the Wiki page where it is and accept a fix to the Makefile > if I > > or someone else has one. I am supporting people who use 2.0.11 on > Windows > > right now. They have some issues which I might need to fix or which > might be > > fixed already in 2.0.12. But I cannot move these people to a moving > target > > 3.0 SVN version. > > > > Isn't it good practice to keep bugfixing the stable version of an app > until > > the next version is out and usually even running for X amount of time? > > > > I can understand that you cannot / don't want to spent time on it, but > others > > might want to. If possible, I'd like to avoid the situation where 2.0 > doesn't > > work and 3.0 isn't there yet. > > You are right that this should be the way to go. In case you want to > contribute > to both 2.x and 3.0 for windows this would be very appreciated. I also did > not > know that there are people actually using Ekiga for win since it was never > officially released... However, like I said before I can give you support > only > on the 3.0 version. > > About 3.0, one known issue is that the DirectShow plugin does not seem to > be > linked correctly anymore since the switch to gcc 4.x. Any hint on that > would > also be very appreciated (provided ekiga runs at all, which I havent tried > for > months...) > > > > About the installer, I have no idea right now except that I will > compare > > > your nsis version with mine... > > > > Which one do you have? On what distro? > > I cannot check before tonight... > > > Regards, > > Torsten > Matthias > > > > Original-Nachricht > > > Datum: Tue, 08 Apr 2008 08:41:36 +0200 > > > Von: Matthias Schneider <[EMAIL PROTECTED]> > > > An: Ekiga development mailing list , > Torsten > > Schlabach <[EMAIL PROTECTED]> > > > CC: Ekiga development mailing list > > > Betreff: Re: [Ekiga-devel-list] win32 build updated > > > > > Quoting Torsten Schlabach <[EMAIL PROTECTED]>: > > &
Re: [Ekiga-devel-list] win32 build updated
Le mardi 08 avril 2008 à 10:57 +0200, Matthias Schneider a écrit : > Hm, is it Kilian's? Damien? I can check tonight if it still works... Hi, It's Kilian's. > > > [2.0 build] > > > What do you mean keep it around? I thought its not working anyway? > I can > > > only tell you I do not have a single minute I can put into > anything > > > related to 2.0.x, actually I had mentally moved the 3.0 windows > buidl to > > > 3.2 already... > > > > I mean: Keep the Wiki page where it is and accept a fix to the > Makefile if I > > or someone else has one. I am supporting people who use 2.0.11 on > Windows > > right now. They have some issues which I might need to fix or which > might be > > fixed already in 2.0.12. But I cannot move these people to a moving > target > > 3.0 SVN version. > > > > Isn't it good practice to keep bugfixing the stable version of an > app until > > the next version is out and usually even running for X amount of > time? > > > > I can understand that you cannot / don't want to spent time on it, > but others > > might want to. If possible, I'd like to avoid the situation where > 2.0 doesn't > > work and 3.0 isn't there yet. > > You are right that this should be the way to go. In case you want to > contribute > to both 2.x and 3.0 for windows this would be very appreciated. I also > did not > know that there are people actually using Ekiga for win since it was > never > officially released... However, like I said before I can give you > support only > on the 3.0 version. At the time we did packaged 2.0.9 for windows there was people using it on ekiga.net (as it showed up first in the white pages). I think it should be some today. Probably TheBonsai could tell how much (asking SER). Regards, Yannick -- Me joindre en téléphonie IP / vidéoconférence ? sip:[EMAIL PROTECTED] Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build updated
Le mardi 08 avril 2008 à 16:45 +0200, yannick a écrit : > Le mardi 08 avril 2008 à 10:57 +0200, Matthias Schneider a écrit : > > Hm, is it Kilian's? Damien? I can check tonight if it still works... > > Hi, > > It's Kilian's. I only host ekiga.org/ekiga.net and mirror the result of the build done by Kilian on another machine (which is not maintained anymore). -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build updated
Damien Sandras wrote: > I only host ekiga.org/ekiga.net and mirror the result of the build done > by Kilian on another machine (which is not maintained anymore). What's not maintained anymore? The machine or the build? Does anyone except Kilian have access to that machine? Would Kilian grant anyone else access to that machine? In case the answer to both questions was "no": If I had a machine (I do, actually) what would it take to make a nightly build happen and mirror it? Don't get me wrong: If Kilian would be so nice, I think this would be the most efficient way. In case he doesn't or cannot help anymore, the question would be if we could at least re-use any scripts from the old box. Regards, Torsten ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build updated
Le mardi 08 avril 2008 à 17:30 +0200, Torsten Schlabach a écrit : > Damien Sandras wrote: > > I only host ekiga.org/ekiga.net and mirror the result of the build done > > by Kilian on another machine (which is not maintained anymore). > > What's not maintained anymore? The machine or the build? Both I suppose. > Does anyone except Kilian have access to that machine? No. > Would Kilian grant anyone else access to that machine? I dont know. Kilian ?? (in CC, if he answers) > In case the answer to both questions was "no": > > If I had a machine (I do, actually) what would it take to make a nightly > build happen and mirror it? > > Don't get me wrong: If Kilian would be so nice, I think this would be the > most efficient way. In case he doesn't or cannot help anymore, the question > would be if we could at least re-use any scripts from the old box. Kilian, can you enlighten us ? -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build updated
Quoting Damien Sandras <[EMAIL PROTECTED]>: > Le mardi 08 avril 2008 à 17:30 +0200, Torsten Schlabach a écrit : > > Damien Sandras wrote: > > > I only host ekiga.org/ekiga.net and mirror the result of the build done > > > by Kilian on another machine (which is not maintained anymore). > > > > What's not maintained anymore? The machine or the build? > > Both I suppose. > > > Does anyone except Kilian have access to that machine? > > No. > > > Would Kilian grant anyone else access to that machine? > > I dont know. Kilian ?? (in CC, if he answers) > > > In case the answer to both questions was "no": > > > > If I had a machine (I do, actually) what would it take to make a nightly > build happen and mirror it? > > > > Don't get me wrong: If Kilian would be so nice, I think this would be the > most efficient way. In case he doesn't or cannot help anymore, the question > would be if we could at least re-use any scripts from the old box. > > Kilian, can you enlighten us ? > -- > _ Damien Sandras Torsten, my NSIS: makensis -VERSION v2.33-1 I am running debian unstable. It seems the build setup is still set up, you can see the logs at http://trinity.buildserver.net/~kk/ekiga_win32_crosscompile.log As far as I know once a file is generated, it should go to http://archive.buildserver.net/win32/ However since there seems to be some manual interaction needed on the build machine I do not know if we can get it up without Kilian... Matthias This message was sent using IMP, the Internet Messaging Program. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] win32 build updated
Quoting Matthias Schneider <[EMAIL PROTECTED]>: > Quoting Damien Sandras <[EMAIL PROTECTED]>: > > > Le mardi 08 avril 2008 à 17:30 +0200, Torsten Schlabach a écrit : > > > Damien Sandras wrote: > > > > I only host ekiga.org/ekiga.net and mirror the result of the build done > > > > by Kilian on another machine (which is not maintained anymore). > > > > > > What's not maintained anymore? The machine or the build? > > > > Both I suppose. > > > > > Does anyone except Kilian have access to that machine? > > > > No. > > > > > Would Kilian grant anyone else access to that machine? > > > > I dont know. Kilian ?? (in CC, if he answers) > > > > > In case the answer to both questions was "no": > > > > > > If I had a machine (I do, actually) what would it take to make a nightly > > build happen and mirror it? > > > > > > Don't get me wrong: If Kilian would be so nice, I think this would be the > > most efficient way. In case he doesn't or cannot help anymore, the question > > would be if we could at least re-use any scripts from the old box. > > > > Kilian, can you enlighten us ? > > -- > > _ Damien Sandras > > Torsten, > my NSIS: > > makensis -VERSION > v2.33-1 > > I am running debian unstable. > > It seems the build setup is still set up, you can see the logs at > http://trinity.buildserver.net/~kk/ekiga_win32_crosscompile.log > > As far as I know once a file is generated, it should go to > http://archive.buildserver.net/win32/ > > However since there seems to be some manual interaction needed on the build > machine I do not know if we can get it up without Kilian... > > Matthias > Hi Torsten, it has been suspected by Robert that the wchar issue in ptlib and opal may be due to the following section in ptlib/include/ptlib/pstring.h: 50 #if (defined(_WIN32) || defined(_WIN32_WCE)) && (!defined(_NATIVE_WCHAR_T_DEFINED)) 51 PBASEARRAY(PWCharArray, unsigned short); 52 #else 53 PBASEARRAY(PWCharArray, wchar_t); 54 #endif Maybe you would like to investigate further? Maybe all that is needed is a fixed #if? Matthias This message was sent using IMP, the Internet Messaging Program. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 building tools
Le lundi 09 février 2009 à 17:50 -0600, Michael Cronenworth a écrit : > Hello, > > I will attempt to build the Win32 package for you guys, but first I'd > like to know if there is any place where I can grab the NSIS installer > script or the list of packages that were used during compiling. I can > fair enough on my own to build it, but I'd like to match the feature > set of the current build. > The guy who made the windows package wrote this: http://wiki.ekiga.org/index.php/Cross-compile_Win32_3.0 ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 building tools
yannick wrote: The guy who made the windows package wrote this: http://wiki.ekiga.org/index.php/Cross-compile_Win32_3.0 Ah... Fedora is now including mingw as well. :) I'll put in a request for a wiki account. Thanks. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 cross compile error
Hi, I'm looking for compiling Ekiga for Win32 on Debian sid 32 bits (and also 64bits) platform. I used svn co http://svn.gnome.org/svn/ekiga/branches/gnome-2-24/win32 to have repository I read related documentation on wiki website. I changed aclocal and automake version to 1.10. I changed also src/ptlib/src/Makefile file at line 338 SOURCES += \ $(PLATFORM_SRC_DIR)/ptlib.cxx \ $(PLATFORM_SRC_DIR)/icmp.cxx \ $(PLATFORM_SRC_DIR)/winsock.cxx \ $(PLATFORM_SRC_DIR)/win32.cxx \ $(PLATFORM_SRC_DIR)/dllmain.cxx \ $(PLATFORM_SRC_DIR)/ethsock.cxx \ + $(PLATFORM_SRC_DIR)/svcproc.cxx \ $(COMMON_SRC_DIR)/pchannel.cxx \ $(COMMON_SRC_DIR)/pethsock.cxx \ $(COMMON_SRC_DIR)/pconfig.cxx else SOURCES += \ $(PLATFORM_SRC_DIR)/uicmp.cxx \ $(PLATFORM_SRC_DIR)/socket.cxx \ $(PLATFORM_SRC_DIR)/udll.cxx \ $(PLATFORM_SRC_DIR)/channel.cxx \ $(PLATFORM_SRC_DIR)/svcproc.cxx \ $(PLATFORM_SRC_DIR)/osutil.cxx \ $(PLATFORM_SRC_DIR)/tlib.cxx \ $(PLATFORM_SRC_DIR)/switch.cxx Here is the result : i586-mingw32msvc-g++ -mms-bitfields -g -mms-bitfields -I/root/win32/include/gtk-2.0 -I/root/win32/lib/gtk-2.0/include -I/root/win32/include/atk-1.0 -I/root/win32/include/cairo -I/root/win32/include/pango-1.0 -I/root/win32/include/glib-2.0 -I/root/win32/lib/glib-2.0/include -I/root/win32/include/libpng12 -mms-bitfields -I/root/win32/include/glib-2.0 -I/root/win32/lib/glib-2.0/include -mms-bitfields -DPTRACING=1 -fno-exceptions -I/root/win32/include -I/root/win32/include/opal -I/root/win32/directx -mms-bitfields -DPTRACING=1 -fno-exceptions -I/root/win32/include -I/root/win32/directx -I/root/win32/include/sigc++-2.0 -I/root/win32/lib/sigc++-2.0/include -I/root/win32/include/libxml2 -I/root/win32/include -march=pentium-mmx -DPTRACING -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -DSTATIC_LIBS_USED -march=pentium-mmx -o ekiga.exe accounts.o callbacks.o conf.o dialpad.o assistant.o main.o misc.o preferences.o statusicon.o statusmenu.o videoinput.o videooutput.o audiodev.o ekiga.o manager.o pcss.o opal-account.o opal-bank.o opal-call.o opal-codec-description.o opal-gmconf-bridge.o opal-main.o h323-endpoint.o sip-chat-simple.o sip-dialect.o sip-endpoint.o -L/root/win32/lib ../lib/.libs/libekiga.a ../lib/engine/.libs/libekiga_engine.a -lddraw -L/root/win32/openldap-2.3.28/lib /root/win32/lib/libldap.dll.a -llutil /root/win32/lib/liblber.dll.a -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lintl -lopal_d_s /root/win32/lib/libspeexdsp.dll.a -lpt_d_s -lwinmm -lwsock32 -lsnmpapi -lmpr -lcomdlg32 -lgdi32 -lavicap32 -liphlpapi -lregex /root/win32/lib/libexpat.dll.a -ldsound -ldxerr9 -ldxguid -lstrmiids -lole32 -luuid -loleaut32 -lquartz -ldnsapi /root/win32/lib/libsigc-2.0.dll.a /root/win32/lib/libxml2.dll.a -lz -lws2_32 -L/root/win32/lib -L/root/win32/lib /root/win32/lib/libpt_d_s.a(ptime.o):/root/win32/ptlib/src/ptlib/common/ptime.cxx:597: undefined reference to `_PTimeParse' collect2: ld returned 1 exit status make[4]: *** [ekiga.exe] Error 1 make[4]: Leaving directory `/root/win32/ekiga/src' make[3]: *** [all] Error 2 make[3]: Leaving directory `/root/win32/ekiga/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/win32/ekiga' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/win32/ekiga' make: *** [/root/win32/ekiga/src/ekiga.exe] Error 2 Is anybody have an idea? -- Thierry Simonnet ESIEE – Paris Environnement Par respect pour l’environnement, n’imprimez ce mail que si nécessaire ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Win32 build Debian based
The mingw32-runtime provided by Ubuntu (presumably also Debian) is outdated when compared to Fedora packages. Commit 22039 to vfw.cxx in ptlib requires really new Win32 headers. For those who have the same difficulties compiling it as I had, have a look at http://wwwuser.gwdg.de/~mrickma/ekiga/mingwrt/mingw32-runtime_3.15-1_all.deb Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Michael Rickmann a écrit : Building Win32 Ekiga from current heads is not straightforward. Ekiga, Ptlib and Opal seem to have regressed in some aspects. 1) In Ekiga videooutput-manager-dx.cpp can not be compiled. I tried to fix it with attached patch. There were two major issues: Where does GMVideoDisplay_DX come from? I guess GMVideoOutputManager_dx was ment. My compiler wants the functions at the end, like device_error_in_main, be explicitly made members of class GMVideoOutputManager_dx. Otherwise it would not allow the signals to be inherited. That one is "normal" : I did blind changes a few days ago (see the log commit). Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Julien Puydt a écrit : Michael Rickmann a écrit : Building Win32 Ekiga from current heads is not straightforward. Ekiga, Ptlib and Opal seem to have regressed in some aspects. 1) In Ekiga videooutput-manager-dx.cpp can not be compiled. I tried to fix it with attached patch. There were two major issues: Where does GMVideoDisplay_DX come from? I guess GMVideoOutputManager_dx was ment. My compiler wants the functions at the end, like device_error_in_main, be explicitly made members of class GMVideoOutputManager_dx. Otherwise it would not allow the signals to be inherited. That one is "normal" : I did blind changes a few days ago (see the log commit). Your patch is in! Sorry for the inconvenience, Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Michael Rickmann wrote: Building Win32 Ekiga from current heads is not straightforward. Ekiga, Ptlib and Opal seem to have regressed in some aspects. 1) In Ekiga videooutput-manager-dx.cpp can not be compiled. I tried to fix it with attached patch. There were two major issues: Where does GMVideoDisplay_DX come from? I guess GMVideoOutputManager_dx was ment. My compiler wants the functions at the end, like device_error_in_main, be explicitly made members of class GMVideoOutputManager_dx. Otherwise it would not allow the signals to be inherited. 2) Ekiga with current Ptlib head is unable to detect any audio or video devices - all silence. This seems to be due to the changes introduced with "Replaced PWLibStupidLinkerHacks". I had to go back to revision 22442. I created a bug report for this: https://sourceforge.net/tracker/?func=detail&aid=2781050&group_id=204472&atid=989748 Thanks! -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Eugen Dedu wrote: Michael Rickmann wrote: Building Win32 Ekiga from current heads is not straightforward. Ekiga, Ptlib and Opal seem to have regressed in some aspects. [...] 2) Ekiga with current Ptlib head is unable to detect any audio or video devices - all silence. This seems to be due to the changes introduced with "Replaced PWLibStupidLinkerHacks". I had to go back to revision 22442. I created a bug report for this: https://sourceforge.net/tracker/?func=detail&aid=2781050&group_id=204472&atid=989748 We are stuck with this bug, because upstream does not help. What can we do...? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Eugen Dedu wrote: ..deleted We are stuck with this bug, because upstream does not help. What can we do...? If upstream means Opal, then I think this is being a bit unfair. I use Opal/PTLib on Windows and Linux every day. On both these operating systems, there is no problem. We are extremely busy maintaining support for these two operating systems using their native compilers (gcc and MSVC), as well as bringing in new code and features. I've tried to cross-compile Ekiga for Windows, but it requires a debian box with the latest dev code (Sid?) and I simply can't dedicate a whole machine for this purpose, northe time it would take to make it work. Now, if I could cross-compile ekiga on a Fedora box then I would be REALLY interested. :) Craig -- --- Craig Southeren Post Increment – VoIP Consulting and Software cra...@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax:+61 243656905 MSN: craig_southe...@hotmail.com Mobile: +61 417231046 Jabber: cra...@jabber.org "Science is the poetry of reality." Richard Dawkins ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Craig Southeren wrote: Now, if I could cross-compile ekiga on a Fedora box then I would be REALLY interested. :) The official build on ekiga.net is from a Fedora box. I made that build on Fedora 10. yum install mingw32-gcc ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Michael Cronenworth wrote: Craig Southeren wrote: Now, if I could cross-compile ekiga on a Fedora box then I would be REALLY interested. :) The official build on ekiga.net is from a Fedora box. I made that build on Fedora 10. yum install mingw32-gcc Last time I tried the procedure at the following URL, it didn't even go close to working on Fedora: http://wiki.ekiga.org/index.php/Cross-compile_Win32 Is that this what you did? Were any changes needed? Craig -- --- Craig Southeren Post Increment – VoIP Consulting and Software cra...@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax:+61 243656905 MSN: craig_southe...@hotmail.com Mobile: +61 417231046 Jabber: cra...@jabber.org "Science is the poetry of reality." Richard Dawkins ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Craig Southeren wrote: Last time I tried the procedure at the following URL, it didn't even go close to working on Fedora: http://wiki.ekiga.org/index.php/Cross-compile_Win32 Is that this what you did? Were any changes needed? The Makefile in Gnome SVN/Git is not appropriate for Fedora MinGW. It was made by a guy using Debian. I was not sure how to handle a Fedora Makefile, but I think I will just submit it as "Makefile.fedora" and call it a day. Let me change it to use Gnome Git instead of SVN and I'll post it on this list. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Michael Cronenworth a écrit : Craig Southeren wrote: Last time I tried the procedure at the following URL, it didn't even go close to working on Fedora: http://wiki.ekiga.org/index.php/Cross-compile_Win32 Is that this what you did? Were any changes needed? The Makefile in Gnome SVN/Git is not appropriate for Fedora MinGW. It was made by a guy using Debian. I was not sure how to handle a Fedora Makefile, but I think I will just submit it as "Makefile.fedora" and call it a day. Let me change it to use Gnome Git instead of SVN and I'll post it on this list. Would it be possible to merge them into a single Makefile? Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Win32 Ekiga painful
Am Donnerstag, den 30.04.2009, 17:38 +0200 schrieb Julien Puydt: > Michael Cronenworth a écrit : > > Craig Southeren wrote: > >> Last time I tried the procedure at the following URL, it didn't even > >> go close to working on Fedora: > >> > >> http://wiki.ekiga.org/index.php/Cross-compile_Win32 > >> > >> Is that this what you did? Were any changes needed? > > > > The Makefile in Gnome SVN/Git is not appropriate for Fedora MinGW. It > > was made by a guy using Debian. I was not sure how to handle a Fedora > > Makefile, but I think I will just submit it as "Makefile.fedora" and > > call it a day. Let me change it to use Gnome Git instead of SVN and I'll > > post it on this list. > > Would it be possible to merge them into a single Makefile? > > Snark Yes, I think the differences are simple - I had the Fedora packages installed through Debian alien export DEB_BUILD_GNU_TYPE:=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) is not in Fedora export DEB_HOST_GNU_TYPE:="i586-pc-mingw32" HOST_TOOL_PREFIX:=i586-mingw32msvc are different in Fedora One could use simply use: which fedora-one dpkg-architecture as a test. For me that command returns /usr/bin/dpkg-architecture and /usr/bin/dpkg-architecture returns i486-linux-gnu . Depending on the outcome one could adjust all three. As to the stuck linker bug: I am just working on it. Something seems fishy with the macros at the end of include/ptlib/plugin.h . Possibly they are only for MSVC and we should use the "USE_GCC" mechanism for __MINGW32__. Using slightly changed ones in a separate source file to Ekiga gives some hope: i586-mingw32msvc-nm ekiga/src/.libs/ekiga.exe | grep WindowsMultimedia 00a283e0 d .data $_ZGVZN52PPlugin_PSoundChannel_WindowsMultimedia_RegistrationC1EP14PPluginManagerE7factory 00a29e50 d .data $_ZZN52PPlugin_PSoundChannel_WindowsMultimedia_RegistrationC1EP14PPluginManagerE7factory 008bd37c t .text $_ZN52PPlugin_PSoundChannel_WindowsMultimedia_RegistrationC1EP14PPluginManager 00afb398 B _PPlugin_PSoundChannel_WindowsMultimedia_Registration_Instance 00a24a30 D more for PVideoInputDevice_DirectShow and VideoInputDevice_VideoForWindows I did not get that with the original Ptlib macros, it was zero output. Give me a bit more time. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
