You are not logged in.
Pages: 1
When I run $ ekiga -d 4
I first get the gnome message
No usable audio plugin detected
Ekiga didn't find any usable audio plugin. Make sure that your installation is correct.
After clicking OK, the terminal details then complete as follows:
[gs@myhost ~]$ ekiga -d 4
2006/08/05 15:25:04.313 0:00.425 ekiga Detected audio plugins:
2006/08/05 15:25:04.314 0:00.426 ekiga Detected video p lugins: Picture
2006/08/05 15:25:04.314 0:00.426 ekiga Detected audio plugins:
2006/08/05 15:25:04.314 0:00.426 ekiga Detected video plugins: Picture
2006/08/05 15:26:31.411 1:27.523 ekiga OpalMan Deleted manager.
(ekiga:3314): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT ( object)' failed
[gs@myhost ~]$
I have looked at several possibilities, but does it work out-of-the-box for anyone? Maybe someone has found a workaround or fix?
Thanks
Geoff
What the beep was that?
Offline
I don't know any fix - same for me. Posting on ekiga mailing list didn't help
Offline
It works straight out of the box on arch 32 bit, for me. My best guess is that the arch64 pkg for opal is not quite right. There are quite a few dependencies that could have creaky functionailty, too. So really my only reason for suspecting that is the mention of OpalMan in the terminal display.
Geoff
What the beep was that?
Offline
Ekiga fails to find the audio plug-ins because it only looks in '/usr/lib64/' for the 'pwlib' directory (which is in /usr/lib). Since that directory doesn't exist, it simply fails. Just as a test hack, I created /usr/lib64 and copied the pwlib folder into it. Ekiga starts what I believe is normally. I'm sure a symlink would do the trick. If anyone has success actually using it, please report back.
EDIT------>>>>> Symlink works.
Offline
That was a good catch!
Having had a look at the PKGBUILD, it needs --with-pwlib-dir=/usr/lib.
But it then looks for the pwlib includes at /usr/lib/include/ptlib/pprocess.h. However, they are at /usr/include/ptlib/pprocess.h.
Having done ./configure --help, there is no option for changing this (that I can see). So this means adding an option to the PKGBUILD for pwlib[b] of [b]--includedir=/usr/lib/include.
So, I think the two pkgs would probably need rebuilding in that way.
What the beep was that?
Offline
garnome is including ekiga (it under "desktop" directory), it installed by default.
I removed my sig, cause i select the flag, the flag often the target of enemy.
SAR brain-tumor
[img]http://img91.imageshack.us/img91/460/cellphonethumb0ff.jpg[/img]
Offline
Hey, sounds cool. I'll try to fix it later at home.
@skottish: How have you find out that pwlibs looks in /usr/lib64?
Offline
@skottish: How have you find out that pwlibs looks in /usr/lib64?
Early on when searching forums and mailing lists for the error that we all received, someone suggested to run 'strace' and search the output to see if the error was obvious. I ran it and converted the output to a PDF for quick searching (hurray KPDF!). I didn't find anything interesting, but I did notice that the stuff in /opt/gnome was around 4th in the PATH.
Later on I ran into a mailing list post that asked the question if pwlib existed and if there was anything in it. I searched through a file manager first, found it, and it had audio and video sections. It wasn't until later that I thought to search out the PDF. Sure enough, there was only one reference to pwlib. The rest you know about.
VOIP is my last "show stopper" for 64bit. Everything else I have a suitable replacement for or I don't really need. If Ekiga is fully functional, that should take care of my core functionality.
I'm quickly becoming a satisfied Arch64 user!
Offline
I've tried now for a while. It's not that easy to fix. Link /usr/lib to /usr/lib64 would make it run but we don't want that.
1. --with-pwlib-dir=/usr/lib - wrong. it has to be --with-pwlib-dir=/usr or the whole Ekiga configure file has to be fixed as it uses the ${with_pwlib_dir} as prefix for e.g. ${with_pwlib_dir}/include.
2. Throwing the headers to a different place is also not a good idea. Headers are found as long as you don't break the pwlibdir variable. Anyway I could fix it in better ways using sed. But it's not needed now.
I tried to get rid of all -L/usr/lib64 stuff in ekiga but without any luck. Any starting of ekiga ends up with the same message. The strace output told me that something tries to open a file /usr/lib64/pwlib. But I cannot find out where this call comes. I also gave opal --libdir=/usr without any change.
Other ideas?
Offline
I wonder if pkgconfig is not the issue. I think there is a second version of this script in the gnome directories. Do they work differently? Are both scripts somehow being run? Perhaps they don't keep a proper track of what they find?
Just a thought, since this is a gnome-type app!
Geoff
What the beep was that?
Offline
Lines 2765 to 2772 of configure
case $host_cpu:$ekiga_cv_cc_64bit_output in
powerpc64:yes | s390x:yes | sparc64:yes | x86_64:yes)
libname="lib64"
;;
*:*)
libname="lib"
;;
esac
What d'you think?
What the beep was that?
Offline
Already tried that. I changed lib64 to lib wherever I found it: Makefile, Makefile.in, configure, configure.in also in every subdir. I also changed the ldflag -L/usr/lib64 to -L/usr/lib.
I'm still thinking that one of the deps is the reason why it fails. But ldd /opt/gnome/bin/ekiga gives you a long list. I'm already looking which of them are older than our libmoving so they are candidats to get a rebuild.
Offline
Pages: 1