Version: 0.8.1 (using KDE KDE 3.5.2) Installed from: Compiled From Sources Compiler: gcc 4.0.3 OS: Linux When libgphoto is upgraded to 2.1.99 (and probably upcoming 2.2 version), it does not connect to USB camera (I am using C 350D, but it probably does not matter). I have checked digikam 0.8.1 and 0.8.2-beta1. Version 2.1.99 of libgphoto2 was released on December 26th.
does it work with the command line gphoto2? which exact camera is this? C 350d? Canon 350D? You might need to xswitch the camera "PTP" mode.
It is Canon 350D. It works with command-line gphoto2 and with gtkam (which is a GUI). Digikam works again when you downgrade libgphoto2 to 2.1.6. I always have the PTP mode on. In my opinion, digikam is not compatible with libgphoto2 2.1.99, at least when it comes to connecting to the camera with USB.
I've been dabbling with this bug for a few months now with a Canon A620, after having downgraded to 2.1.6 and back and forth. I saw an addition in the gphoto2 docs about the print-usb-usermap being depreciated. With the pre 2.1.99 I have to add a special entry for the camera in the .usermap to use it as a generic PTP camera. After installing 2.1.99 there is no camera listing at all in digikam and thus no functionality. Using the command line gphoto2 and gtkam, the A620 is properly detected. Relevent line from gphoto2 doc: Note (TODO). print-usb-usermap is deprecated as of 2.1.99.1. Use print-camera-list instead. Description of udev rules and HAL setup missing here.
the bug is present in 0.8.2-rc1 in Mandriva Cooker. Downgrading to libgphoto2-2.1.6-8 fixes it for me.
I see this bug as well, with the new gphoto 2.2.0 release in Debian unstable. I have a "generic PTP camera" set up in digikam, which worked under gphoto 2.1.6 with my PowerShot SD450. Now digikam will not connect to the camera at all to download thumbnails etc, nor will it auto-detect my camera. The camera works fine from the command line with the gphoto2 utility: auto-detection, downloads, etc.
libgphoto2 2.2.0 has a new library major version. you need to recompile digikam very likely. you can see this if you try to list all available cameras in digikam.
I have found a fix to this bug, for Debian at least (no recompile of digikam needed). Install the libgphoto2-2-dev package. Then everything works fine in digikam: auto-detect, connecting to camera, downloading, etc. None of these features work without the -dev package. I cannot tell what is in that package that might make a difference: the only binaries I see are gphoto2-port-config, gphoto2-config, libgphoto2_port.so, and libgphoto2.so. The rest are documentation files, headers, and various .a and .la camera libraries.
then its likely the missing .la files for the camera drivers and port drivers. While libtool .la files are usually only used during compilation, for libgphoto2 they are used during runtime too.
Gilles, can't you link against this?
libgphoto2 does not have a new major... It is still .so.2
Reproduceable in Kubuntu/Dapper and SuSE 10.1. #6 (Marcus Meisner) #10 (Hubert Fuguiere): also in Kubuntu/Dapper and debian/sid libghoto2 2.1.6 and 2.2.0 (rebuild debian pkg in dapper) have both major version 2: $ l 2.*/usr/lib/libgph*.so.2.* -rw-r--r-- 1 ach ach 101800 2006-05-10 16:31 2.1.6/usr/lib/libgphoto2.so.2.0.3 -rw-r--r-- 1 ach ach 101696 2006-06-20 00:40 2.2/usr/lib/libgphoto2.so.2.1.0 $ objdump -p 2.*/usr/lib/libgph*.so.2.* | grep SONAME SONAME libgphoto2.so.2 SONAME libgphoto2.so.2 Gilles and I tried to rebuild digikam with libgphoto2-2 installed. Still without the 2.2.0's .la files camera list is empty. So it's a runtime, not a build time problem. One difference between 2.1.6 and 2.2.0 is that the camera plugins are /usr/lib/libgphoto2/2.1.6/libgphoto2_<type>.so and /usr/lib/libghoto2/2.2.0/<type>.so respectively. With strace one gets: $ strace digikam --detect-camera 2>&1 | grep /usr/lib/libgphoto2/2.2.0/ open("/usr/lib/libgphoto2/2.2.0/adc65.la", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libgphoto2/2.2.0/adc65", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libgphoto2/2.2.0/agfa_cl20.la", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libgphoto2/2.2.0/agfa_cl20", O_RDONLY) = -1 ENOENT (No such file or directory) ... and for gtkkam instead allee(130) ~/tmp $ strace gtkam 2>&1 | grep /usr/lib/libgphoto2/2.2.0/ open("/usr/lib/libgphoto2/2.2.0/adc65.la", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libgphoto2/2.2.0/adc65.so", O_RDONLY) = 5 open("/usr/lib/libgphoto2/2.2.0/agfa_cl20.la", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libgphoto2/2.2.0/agfa_cl20.so", O_RDONLY) = 5 So while gtkam and digikam use the same libgphoto2 $ ldd /usr/bin/digikam | grep libgphoto libgphoto2.so.2 => /usr/lib/libgphoto2.so.2 (0xb6565000) libgphoto2_port.so.0 => /usr/lib/libgphoto2_port.so.0 (0xb653e000) $ ldd /usr/bin/gtkam | grep libgphoto libgphoto2.so.2 => /usr/lib/libgphoto2.so.2 (0xb7f0c000) libgphoto2_port.so.0 => /usr/lib/libgphoto2_port.so.0 (0xb7f05000) the sequence of files that the apps try to open differ. digikam: .la, then "" gtkam: .la, then .so With the .la files installed digikam tries .la then .so as gtkam does even without the .la files. [the .la files are in kubuntu and debian in the pkg libghoto2-2-dev, that's the reason why the hack/workaround of installing the 2.2.0 devel pkgs fixes a runtime problem] Both use the same ltdl library: $ ldd /usr/bin/digikam /usr/bin/gtkam | grep ltdl libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb62ec000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb761d000) I've no glue yet what goes wrong. My guess is that somehow KDE seems to influence the list of extentions and makes digikam/libghoto2 combo fail to dynamicly load the camera drivers. coolo ping? ;) Achim
FWIW: libghoto2 2.2.0 contains a subdir libltdl and the code in their is at least compiled. It's too late now to check if it's used/linked. Nite! Achim
gphoto2 2.2 is out and this bug is still valid.
I can confirm this bug on Gentoo, using gphoto2 2.2 and a Canon Digital Ixus 50.
Debian related bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396249
Solved today in Debian Sid: digiKam Debian changelog: ------------------------------------------ digikam (1:0.9.0~beta3-3) unstable; urgency=low [ Mark Purcell ] [...] * Re-Add Build-Depends: libgphoto2-2-dev - libgphoto2-2-dev needed (Closes: #396249) [...] -- Debian KDE Extras Team <pkg-kde-extras@lists.alioth.debian.org> Sat, 4 Nov 2006 10:12:50 +0000 ------------------------------------------
Benjamí, Something have been changed in digiKam Debian package to solve this problem ? I want mean something must be changed in current digiKam implementation ? If no, i will close this file... Gilles
Gilles, I'm not sure you can close the bug for that. We should check if it is *only* a distro issue or not recall: Re-Add Build-Depends: libgphoto2-2-dev IIRC, mandriva patched digikam as well to have a libgphoto-devel dependency, now I wonder why digikam needs a devel package to run.... My 2 €cents Angelo
Hi Angelo, Gilles, Problem is that the new libgphoto plugin names without the 'lib' prefix are not found without the .la files that are in the -devel pkgs. Solutions: move .la files run -devel to -runtime pkgs or find/patch the code so plugins without 'lib' prefix are found without the .la files (see comment #11). Then the dependency on the -devel pkg can be removed. I doubt that it's digikam's fault. IMHO the bug should not be closed but reassigned to the 'lookup plugin' code. (remember gtkam finds the new plugin names without problem, see comment #11) Achim
the .la files for the camlibs and ports MUST be in the runtime package. they are NOT development files, but are used during runtime. tell this to the libgphoto2 packager ;)
Gilles, Only that libgphoto2-2-dev now is needed in Debian [Sid]. Changelog says: * Re-Add Build-Depends: libgphoto2-2-dev - libgphoto2-2-dev needed (Closes: #396249) Angelo: a friend says that in Ubuntu Edgy he have libgphoto2-2-dev dependency too. Benjamí
> Angelo: a friend says that in Ubuntu Edgy he have libgphoto2-2-dev dependency too. That probably means it's a packaging issue...
Just a wild guess: (had this troubles too) using udev (but maybe with wrong rules?) 1. check if it works as root -> if yes continue 2. check you got write permissions on your camera $ ls -l /dev/bus/usb/*/* -> have a look at the respective device... You don't? -> set them manually and check if it works now... Solution: you probably want to update your libgphoto package to a recent version or correct the udev rules manually. PS: Need more information: see http://bugs.gentoo.org/show_bug.cgi?id=153471
From a Debian perspective depending on libgphoto2-2-dev is just a workaround. The real issue is getting the .la files into the runtime package. We are now tracking this issue at http://bugs.debian.org/390703 Mark
I wonder why digikam does not use the .so prefix. It is very strange. Using the .la files will fix it, but perhaps someone should check why it does not look for .so. :/
i can confirm this behavior on openSUSE 10.2 too.
Marcus has just informed me that the .la files are not necessary. On Friday 19 January 2007 18:34, Marcus Meissner wrote: > Err, actually the .la files not necessary as I now know. ... Sorry for the confusion. So what is the solution? Does digikam need to be patched to access the .so files and not the .la files, per comment #11 from Achim above?? Mark
msp: my mistake... in this case they seem to be as bug workaround for digikam. I have tried finding on why digikam is special here, but so far not much success.
Breakpoint 3, 0x00002b99bab7df70 in lt_dlopenext () from /opt/kde3/lib64/libkdecore.so.4 it has its own libltdl compiled in. We use lt_dlopenext ("foo.so"); and it does not handle it correctly => the KDE libltdl version is too old for the stuff libgphoto2 does with it :(
So we need to upgrade kdelibs' internal libltdl. Is that safe?
It would help more to have LTDL_SHLIB_EXT supported in this libltdl copy. if LTDL_SHLIB_EXT is set (to ".so" on Linux), the code would work.
so something like CFLAGS=-DLTDL_SHLIB_EXT=".so" ./configure should work for kdelibs?
The bug seems to be still alive with digikam 2:0.8.2-3 libgphoto2-2 2.2.1-12 libgphoto2-2-dev 2.2.1-12 on debian testing using our canon EOS 350D in PTP mode (non-PTP mode doesn't work either, but PTP-mode worked fine before the upgrade).
Marcus, Is the problem with digiKam Makefile.am and libgphoto2 ? If Kamera tool work fine, well take a look of the current Makefile.am relevant here: http://websvn.kde.org/branches/KDE/3.5/kdegraphics/kamera/kioslave/Makefile.am?rev=466285&view=auto ... and compare with digiKam Makefile.am: ==> for the camera gui : http://websvn.kde.org/trunk/extragear/graphics/digikam/utilities/cameragui/Makefile.am?rev=610979&view=auto Look like it's different, especially about LDFLAGS stuff and $(GPHOTO2_LIBS) witch is not present in cameragui Makefile.am. This can be the problem ? Gilles Caulier
I confirm this with FC-6 and Olympus 3030 hardware today, also gphoto2 result. My FC-6 is a fresh install with all updates per two days ago. See comment #33 / all revs are later than those listed. Add digiKam is R0.9.0(Using KDE 3.5.5-...fc6), gphoto2 is R2.3.1 Analysis: With digiKam -- The camera connect request First opens a camera window - then opens a fatal error window. "Failed to connect to the camera. ..." With gphoto2 --list ports Two ports found prior to camera - ptpip:, and usb: Two more found after camera "ON" - usb:001,004, usb:002,003 With gphoto --auto-detect Olympus C-2100UZ found (wrong!? Olympus-3030Z also exists in .fdi) May not matter? from inspection of .fdi, 2100UZ and 3030Z seem similar... Forcing use of C-3030Z yields same result. Two ports listed - usb:, usb:001,005 I suspect first (without x,y) entry may be incorrect...? NOTE! from /proc/bus/usb directory listing usb:001,005 does exist with OK UID & permissions usb:002,003 does exist with only root perms usb:001,004 does not exist (see --list ports above) With gphoto2 -a On the surface the output seems normal and correct With gphoto2 ... -l Fatal error: "Could not release interface 0 (Invalid argument)." I have debug trace available -- if useful eamil me for attachment... Error began with this: "...gphoto2-port(0): Could not query kernel driver of device" NOTE: My FC-5 had lesser problem - only root could use USB camera interface. Today the issue is a more total failure, probably with HAL and setting USB drivers. I find nothing to adjust nor a workaround. Advise if I can can further test.
After fiddling around with gphoto2 I finally got my Canon EOS 350D working (again): 1) I had to add users to group plugdev (group camera is not used any more). Well so far simply some permissions. 2) I had to use CANON EOS 350D without(!) PTP mode despite the camera itself is still set to PTP connection (PC connection does not work!). Funny, isn't it? So at least my bugreport should better be posted to the gphoto dev. Just for information: digikam 2:0.8.2-4 libgphoto2-2 2.2.1-12 libgphoto2-2-dev 2.2.1-12 gphoto2 2.2.0-3 on debian testing Norbert Pfistner
Ubuntu are claiming they have been able to fix this issue due to the way Kubuntu KDE finds the gphoto libs.. I can confirm this issue is not fixed in Debian with KDE 3.5.7 and digikam 0.9.2 final. Thus Debian is continuing to ship with a dependency on libgphoto2-2-dev. I have asked the Ubuntu guys, what changes they made to kdelibs... Mark
Created attachment 21091 [details] The Camera dialog with libgphoto2-2-dev installed
Created attachment 21092 [details] Camera dialog without libgphoto2-2-dev
The Ubuntu bug report is at https://launchpad.net/bugs/145239
Thanks to pusling this seems to fix: --- kdelibs-3.5.8.dfsg.1.orig/libltdl/ltdl.c +++ kdelibs-3.5.8.dfsg.1/libltdl/ltdl.c @@ -184,6 +184,7 @@ #define LT_DLSTRERROR(name) lt_dlerror_strings[LT_CONC(LT_ERROR_,name)] static const char objdir[] = LTDL_OBJDIR; +#define LTDL_SHLIB_EXT ".so" #ifdef LTDL_SHLIB_EXT static const char shlib_ext[] = LTDL_SHLIB_EXT; #endif
Mark, What's this patch. Where it is applied exactly ??? Sound like a file from KDE core library... Right ??? Laurent, Please, please, please take a look and fix it in svn... (:=))) Gilles
This is what pusling has done with Debian kdelibs: kdelibs (4:3.5.8.dfsg.1-4) unstable; urgency=low * Add a patch to allow to dlopen .so files and not only .la files. Now kamera, digikam and others doesn't need to depend on -dev packages. -- Sune Vuorela <debian@pusling.com> Mon, 12 Nov 2007 13:00:41 +0100
Mark, Thanks a lots for this patch. This is what i suspected but never find it... So, the problem come from KDELibs. This one need to be patched in svn to close this file definitively... Angelo, For Mandriva package, i recommend you to patch kdelibs temporally, as Debian team... Gilles Caulier
To KDE-Libs team : I re-affect this file to your part. The solution to solve it is described by Debian team in #41 and #43. Patch is really simple and easy to test. Please take a look. Thanks in advance... Gilles Caulier
To add a bit more details. It seems that gphoto dlopens its plugins (on debian placed in /usr/lib/libgphoto2/2.4.0/) gphoto uses normally the system libltdl to do the dlopens. But in this case ... kdelibs ships its own embedded libltdl - and in kde applications kdelibs gets loaded first - and then "wins" over the systems other libraries when looking for some functions. The real fix would be to use the system libltdl instead of embedding a copy in kdelibs. (it was comments 31 and 32 that lead me in the right direction - but I just couldn't find the proper way to escape the ".so" if I wanted a -DLTDL_SHLIB_EXT=".so" passed in. That should do the trick as well)
I just made kdelibs build against external libltdl instead of the embedded one. I wonder how much breakage to expect from this. Any clues what to test ? The usage of lt_dlopen_flag in kinit.cpp and klibloader.cpp needed to go away to make it build. I have no clue wether it breaks anything or not.
oh well.. it just broke kded and maybe a couple of other things. Using external libltdl is not recommended right now at least. /Sune
Any news on this with recent versions ?
We fixed this is Debian with a patch to kdelibs.. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416123 kdelibs (4:3.5.8.dfsg.1-4) unstable; urgency=low * Add a patch to allow to dlopen .so files and not only .la files. Now kamera, digikam and others doesn't need to depend on -dev packages. -- Sune Vuorela <debian@pusling.com> Mon, 12 Nov 2007 13:00:41 +010 All looks good in KDE4 too. Mark
Since I am using recent version of KDE4 and digikam (on archlinux - the package contains no patches), things work for me, and I am ready to close this bug report. Should I close it, or should it still be open?
It's fine for me to close this file. Any objections from others peoples ? Gilles Caulier
No objections since more than half a year. Closing this now.