Re: [Ekiga-devel-list] Cross-compiling ekiga for win32
Am Freitag, den 26.06.2009, 01:48 +0200 schrieb Julien Puydt:
Michael Cronenworth a écrit :
It depends on what OS you are building on. The files in win32/ are meant
for Debian. For Fedora or Windows you would need to customize it a little.
I'm using debian. I already had a few problems :
- libxml' 2.6.26 isn't available anymore ;
- the openldap compilation fails with :
slapdmsg.rc -O coff -o slapdmsg.res
make[1]: slapdmsg.rc : commande introuvable (means: command not found)
the Makefile (openldap's libraries/liblutil/ Makefile to be precise)
target triggering the problem is :
lapdmsg.res: slapdmsg.rc slapdmsg.bin
$ -O coff -o $@
which doesn't look very honest.
It's pretty late... uh... early, so I don't think I'll be able to get
myself out of this problem before some rest :-/
Snark
Over the weekend I have stripped down my build process and can make a
suggestion how to revise Ekiga's Win32 build - Debian based only, sorry,
but better than the current.
First, I would like to submit three patches which should go to Ekiga's
code directly.
1ekiga_linkmagic.diff allows the linker to choose the correct entry
point for a Win32 gui application, so that one can use the -mwindows
flag.
2ekiga_shownormal.diff fixes a bug in the installer which would render
Ekiga unusable after a default installation. To start Ekiga minimized
you have to use Ekiga's own option not the Windows' one.
3ekiga_mvredir.diff fixes a problem under Windows 7 (possibly Vista
too). Current Ekiga writes its log files into the application directory.
Win7 allows this, but the files are sometimes truncated or they just
vanish. It appears they use some mapping to protect the application
programs. I would suggest to write the log files onto the user's desktop
if debug output was requested.
Now to the Ekiga's win32 directory. The current diff subdirectory
containes useless diffs. It is needed, however, to hold permanent and
temporary patches. Currently there are three for opal and one for ptlib
- I will file bug reports for them. The ptlib one is especially nasty
because it is Mingw's Win32 headers which are wrong (the WINVER issue),
but they seem to prefer being on the conservative side.
Finally, in the Makefile I have upgraded the versions of the required
libs mostly. libsasl2 and celt were added. And I changed to downloading
from git where required (Ekiga) or more reliable (ffmpeg).
I attach two forms of the changes to the win32 subdir, a long patch and
as an archive of the changed / required files.
As we cannot download the win32 subdir separately from git. Starting to
build Ekiga would change as follows.
Obtain Ekiga
git clone git://git.gnome.org/ekiga
Make a copy of the win32 directory
cp -a ekiga/win32 .
Change into that subdirectory, it will be your BUILDROOT
cd win32
Get all the sources
make update-sources
Build Ekiga
make
The Makefile will try to move the already downloaded Ekiga to the right
place during the make update-sources.
I hope it helps.
Regards
Michael
diff -ur ekiga.orig/src/gui/main.cpp ekiga/src/gui/main.cpp
--- ekiga.orig/src/gui/main.cpp 2009-06-28 08:17:31.0 +0200
+++ ekiga/src/gui/main.cpp 2009-06-28 08:18:58.0 +0200
@@ -4307,6 +4307,10 @@
return gtk_image_get_pixbuf (GTK_IMAGE (mw-priv-main_video_image));
}
+#ifdef WIN32
+// the linker must not find main
+#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
diff -ur ekiga.orig/src/gui/main.cpp ekiga/src/gui/main.cpp
--- ekiga.orig/src/gui/main.cpp 2009-06-28 08:22:05.0 +0200
+++ ekiga/src/gui/main.cpp 2009-06-28 08:23:30.0 +0200
@@ -4410,6 +4410,13 @@
text_label = g_strdup_printf (PTLIB_TRACE_CODECS_USER_PLANE=%d, debug_level_up);
_putenv (text_label);
g_free (text_label);
+ if (debug_level != 0) {
+string desk_path = g_get_user_special_dir (G_USER_DIRECTORY_DESKTOP);
+if (!desk_path.empty ()) {
+ std::freopen((desk_path + \\ekiga-stdout.txt).c_str (), w, stdout);
+ std::freopen((desk_path + \\ekiga-stderr.txt).c_str (), w, stderr);
+}
+ }
#endif
/* Ekiga initialisation */
@@ -4579,9 +4586,6 @@
/* use msvcrt.dll to parse command line */
__getmainargs (argc, argv, env, 0, info);
-std::freopen(stdout.txt, w, stdout);
-std::freopen(stderr.txt, w, stderr);
-
iresult = main (argc, argv, env);
}
CloseHandle (ekr_mutex);
win32.diff.gz
Description: GNU Zip compressed data
Re: [Ekiga-devel-list] Cross-compiling ekiga for win32
Michael Rickmann a écrit : big snip I pushed all your changes in. There's something I don't get : why do you want to download ekiga if you already have it on disk? Perhaps it's something you don't know about autotools : they allow out-of-tree builds. You have your sources in $WHATEVER_DIR, but want to build in $THIS_DIR : $ mkdir -p $THIS_DIR $ cd $THIS_DIR $ $WHATEVER_DIR/configure $CONFFLAGS $ make This will build the usual program ; if in another console you do : $ ~/bin/setup_for_cross_compile $ mkdir -p $(THIS_DIR)_cross $ cd $(THIS_DIR)_cross $ $WHATEVER_DIR/configure $CROSS_CONFFLAGS $ make Then the same sources will be built with very different options in different directories. Hope this helps, Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Cross-compiling ekiga for win32
Am Montag, den 29.06.2009, 14:19 +0200 schrieb Julien Puydt: Michael Rickmann a écrit : big snip I pushed all your changes in. Thanks, I will test it as soon as possible. It should be ok, one never knows. There's something I don't get : why do you want to download ekiga if you already have it on disk? make tries to move the download if it finds it at the most probable location: ifeq ($(wildcard $(SRCDIR)/$(EKIGA_ARCHIVE)),) ifneq ($(wildcard $(BUILDROOT)/../$(EKIGA_ARCHIVE)/.git),) update-ekiga: echo --- Moving Ekiga master... $(MV) $(BUILDROOT)/../$(EKIGA_ARCHIVE) $(SRCDIR) else I and the Makefile are just used to have all sources in one subdir. Perhaps it's something you don't know about autotools : they allow out-of-tree builds. You have your sources in $WHATEVER_DIR, but want to build in $THIS_DIR : $ mkdir -p $THIS_DIR $ cd $THIS_DIR $ $WHATEVER_DIR/configure $CONFFLAGS $ make This will build the usual program ; if in another console you do : $ ~/bin/setup_for_cross_compile $ mkdir -p $(THIS_DIR)_cross $ cd $(THIS_DIR)_cross $ $WHATEVER_DIR/configure $CROSS_CONFFLAGS $ make Then the same sources will be built with very different options in different directories. Now I remember, I used that when I was building the cross tools myself, gcc uses that scheme. Hope this helps, It may come in the next revision of the Makefile for a couple of sources. For those sources, which we are working on, copying the source and building in tree was what the Makefile was providing for up to now, but building from a separate git clone may be even easier. Snark ___ 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] alien registrar problem
Damien Sandras wrote: [...] It tells: SIP/2.0 403 Keine RFC1918-IPs erlaubt [...] What happens is that your contact field has 2 IP addresses : - 1 public IP - 1 private IP (with lower priority) The remote SER is misconfigured and rejects the packets because one of the IPs is private while the public one is reachable. You should contact them. I'm having the same problem, however with another provider (bluesip.net). The relevant debug output is: rem=udp$217.74.179.29:5060,local=udp$96.232.27.238:5060,if=192.168.1.36%wlan0 SIP/2.0 479 Please don't use private IP addresses Concerning to another voip forum, the responsibilty of this issue is on the client site, i.e. ekiga in this case. It seems that ekiga's behavior isn't sip-standard conform here (I'm no expert, though). The only unsatisfactory solution for me rigth now is to use twinkle with this specific provider. Is there a chance that ekiga switches it's behavior? Chris ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Le lundi 29 juin 2009 à 11:33 -0400, Christian Schäfer a écrit : Damien Sandras wrote: Le lundi 29 juin 2009 à 11:02 -0400, Christian Schäfer a écrit : Damien Sandras wrote: [...] It tells: SIP/2.0 403 Keine RFC1918-IPs erlaubt [...] What happens is that your contact field has 2 IP addresses : - 1 public IP - 1 private IP (with lower priority) The remote SER is misconfigured and rejects the packets because one of the IPs is private while the public one is reachable. You should contact them. I'm having the same problem, however with another provider (bluesip.net). The relevant debug output is: rem=udp$217.74.179.29:5060,local=udp$96.232.27.238:5060,if=192.168.1.36%wlan0 SIP/2.0 479 Please don't use private IP addresses Concerning to another voip forum, the responsibilty of this issue is on the client site, i.e. ekiga in this case. It seems that ekiga's behavior isn't sip-standard conform here (I'm no expert, though). The only unsatisfactory solution for me rigth now is to use twinkle with this specific provider. Is there a chance that ekiga switches it's behavior? I would be happy to change the behavior if Ekiga was not sip conform, but I have no idea what to change. I also have some doubts. Wouldn't it be STUN? Have you tried disabling it? The problem is independent from whether using STUN or not, and it only appears when I am behind a NAT. As a result, the local IP address (192.168.1.36 in my case) somehow gets through to the provider. To my understanding the IP needs to be replaced with the WAN address by ekiga. Most providers seem to ignore this non-sip-standard behavior, however bluesip (and some others) seem to be more strict. (google for Please don't use private IP addresses) Ekiga.net also rejects private IP addresses and all Ekiga clients behave fine. The problem is that your router replaces the public IP address Ekiga puts in by a private one due to a bug in the router itself, you can see the Ekiga PDUs in the log, they are correct. If you disable STUN, perhaps your router will put the public IP address in the packets. What happens is that some dummy routers replace public ip's by private ones. That's your case. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Damien Sandras wrote: Wouldn't it be STUN? Have you tried disabling it? The problem is independent from whether using STUN or not, and it only appears when I am behind a NAT. As a result, the local IP address (192.168.1.36 in my case) somehow gets through to the provider. To my understanding the IP needs to be replaced with the WAN address by ekiga. Most providers seem to ignore this non-sip-standard behavior, however bluesip (and some others) seem to be more strict. (google for Please don't use private IP addresses) Ekiga.net also rejects private IP addresses and all Ekiga clients behave fine. The problem is that your router replaces the public IP address Ekiga puts in by a private one due to a bug in the router itself, you can see the Ekiga PDUs in the log, they are correct. If you disable STUN, perhaps your router will put the public IP address in the packets. What happens is that some dummy routers replace public ip's by private ones. That's your case. Don't think that's true. As I said, using twinkle behind the NAT with the same router works perfectly with that provider. So the router couldn't be the problem here and it seems that it's indeed a software issue. Chris ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
The problem is that your router replaces the public IP address Ekiga puts in by a private one due to a bug in the router itself, you can see the Ekiga PDUs in the log, they are correct. If you disable STUN, perhaps your router will put the public IP address in the packets. What happens is that some dummy routers replace public ip's by private ones. That's your case. Don't think that's true. As I said, using twinkle behind the NAT with the same router works perfectly with that provider. So the router couldn't be the problem here and it seems that it's indeed a software issue. Please show me a trace of Ekiga with stun disabled and a trace of twinkle so that we can compare both. Btw, I don't understand your reasoning which consists to say that Ekiga puts deliberately private IP addresses in PDUs when the log says no. Again, to clearify my reasoning, these are the relevant observations: Firstly: Relevant -d 4 output of ekiga says the following when trying to connect to bluesip.net: rem=udp$217.74.179.29:5060,local=udp$96.232.27.238:5060,if=192.168.1.36%wlan0 SIP/2.0 479 Please don't use private IP addresses This suggests that there's a problem with the private IP address (192.168.1.36). Whether this is sip conform or not I dodn't know. Concerning to some people in some voip forums, it isn't. Secondly: This behavior is independent of using a STUN server or not and only appears when I am behind a NAT router. And thirdly: The fact that twinkle is able to connect to bluesip successfully from behind this specific router, suggests that this is no router-issue. This issue sounds quite familiar to a couple of bugs I've had reported on F-11 where they are unable to connect to a SIP server where with previous versions of ekiga they were (in some cases they even went as far as recompiling ekiga 2 themselves. Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] alien registrar problem
Christian Schäfer schrieb: Damien Sandras wrote: The problem is that your router replaces the public IP address Ekiga puts in by a private one due to a bug in the router itself, you can see the Ekiga PDUs in the log, they are correct. If you disable STUN, perhaps your router will put the public IP address in the packets. What happens is that some dummy routers replace public ip's by private ones. That's your case. Don't think that's true. As I said, using twinkle behind the NAT with the same router works perfectly with that provider. So the router couldn't be the problem here and it seems that it's indeed a software issue. Please show me a trace of Ekiga with stun disabled and a trace of twinkle so that we can compare both. Btw, I don't understand your reasoning which consists to say that Ekiga puts deliberately private IP addresses in PDUs when the log says no. Again, to clearify my reasoning, these are the relevant observations: Firstly: Relevant -d 4 output of ekiga says the following when trying to connect to bluesip.net: rem=udp$217.74.179.29:5060,local=udp$96.232.27.238:5060,if=192.168.1.36%wlan0 SIP/2.0 479 Please don't use private IP addresses This suggests that there's a problem with the private IP address (192.168.1.36). Whether this is sip conform or not I dodn't know. Concerning to some people in some voip forums, it isn't. Secondly: This behavior is independent of using a STUN server or not and only appears when I am behind a NAT router. And thirdly: The fact that twinkle is able to connect to bluesip successfully from behind this specific router, suggests that this is no router-issue. Detailed traces of both ekiga and twinkle will follow. Chris Hi, I think a -d 4 trace and something from twinkle might really help Ekiga. When I tried from a machine with official internet access the line containing your rem=.. contained rem=udp$212.227.15.231:5060,local=udp$134.76.145.30:5060,if=134.76.145.30%eth0 but a few lines up: Contact: sip:495512963...@134.76.145.30;q=1, sip:495512963...@192.168.21.30;q=0.500 because the machine had a second interface to a local network. result from sip.1und1.de: SIP/2.0 403 Keine RFC1918-IPs erlaubt 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] alien registrar problem
Peter Robinson wrote: The problem is that your router replaces the public IP address Ekiga puts in by a private one due to a bug in the router itself, you can see the Ekiga PDUs in the log, they are correct. If you disable STUN, perhaps your router will put the public IP address in the packets. What happens is that some dummy routers replace public ip's by private ones. That's your case. Don't think that's true. As I said, using twinkle behind the NAT with the same router works perfectly with that provider. So the router couldn't be the problem here and it seems that it's indeed a software issue. Please show me a trace of Ekiga with stun disabled and a trace of twinkle so that we can compare both. Btw, I don't understand your reasoning which consists to say that Ekiga puts deliberately private IP addresses in PDUs when the log says no. Again, to clearify my reasoning, these are the relevant observations: Firstly: Relevant -d 4 output of ekiga says the following when trying to connect to bluesip.net: rem=udp$217.74.179.29:5060,local=udp$96.232.27.238:5060,if=192.168.1.36%wlan0 SIP/2.0 479 Please don't use private IP addresses This suggests that there's a problem with the private IP address (192.168.1.36). Whether this is sip conform or not I dodn't know. Concerning to some people in some voip forums, it isn't. Secondly: This behavior is independent of using a STUN server or not and only appears when I am behind a NAT router. And thirdly: The fact that twinkle is able to connect to bluesip successfully from behind this specific router, suggests that this is no router-issue. This issue sounds quite familiar to a couple of bugs I've had reported on F-11 where they are unable to connect to a SIP server where with previous versions of ekiga they were (in some cases they even went as far as recompiling ekiga 2 themselves. The bugs were because the local= address was private, not the if= address. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
