Bug 363638 - bootstrap does not detect libgphoto2
Summary: bootstrap does not detect libgphoto2
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Portability-Runtime (show other bugs)
Version: 5.0.0
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-28 19:34 UTC by Simon
Modified: 2017-07-15 22:13 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.0


Attachments
remove typos from FIndGphoto2.cmake and make it more verbose (2.78 KB, patch)
2016-06-02 21:32 UTC, Simon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simon 2016-05-28 19:34:58 UTC
When I run the bootstrap script it always tells me that it does not find libgphoto2 (above version 2.4.0). However I do have the package libgphoto2-dev from debian repos installed, which are version 2.5.10-2 (-2 is debian specific, rest major version).

Reproducible: Always
Comment 1 caulier.gilles 2016-06-01 18:34:09 UTC
Git commit f1f247f1cc71e948c377ec7d1daa1389728fe88c by Gilles Caulier.
Committed on 01/06/2016 at 18:32.
Pushed by cgilles into branch 'master'.

be more verboze about dependency with libusb1 required by libgphoto2 to prevent crash when libopencv is linked with libdc1394.
See bug #268267 for details about this problem.
FIXED-IN: 5.0.0

M  +1    -0    CMakeLists.txt
M  +1    -1    README

http://commits.kde.org/digikam/f1f247f1cc71e948c377ec7d1daa1389728fe88c
Comment 2 Simon 2016-06-01 22:20:22 UTC
With commit f1f247f1cc71e948c377ec7d1daa1389728fe88c I still get the following output:

--  libgphoto2 found......................... NO  (optional)
--  digiKam will be compiled without GPhoto2 camera drivers support.
--  Please install the libgphoto2 (version >= 2.4.0) development package.
-- 

I do and did have libusb 1.0.20 and libgphoto 2.5.10 both with -dev packages installed.
Comment 3 caulier.gilles 2016-06-02 03:47:45 UTC
Give me the full backtrace of configuration stage

Gilles Caulier
Comment 4 caulier.gilles 2016-06-02 07:01:04 UTC
It must miss libusb1. This is required to prevent conflict with opencv. See bug #268267 for details.

In your configuration trace you must see something like that :
...
-- Found gphoto2: -L/usr/lib64 -lgphoto2_port;-L/usr/lib64 -lgphoto2 -lgphoto2_port -lm
-- Found LibUSB1: /usr/lib64/libusb-1.0.so  
-- LibUSB1_FOUND        = TRUE
-- LibUSB1_INCLUDE_DIRS = /usr/include/libusb-1.0
-- LibUSB1_LIBRARIES    = /usr/lib64/libusb-1.0.so
CMake Warning at core/CMakeLists.txt:351 (message):
  libgphoto2 is found but libusb1 cannot be found on your system.
  libgphoto2 support will be disabled.
...

Gilles Caulier
Comment 5 Simon 2016-06-02 12:09:04 UTC
I do not see anything related to libusb and still the same for 
libgphoto. I am running the boostrap script on softwarecomp commit 
"d30542149650693a58b355aab944fea4e7be6e09" and core commit 
"e74ea61a3177d964474a04dc1460c1500811bec6". The full output of the 
bootstrap can be found on http://pastebin.com/RtgXyHsC

On 02/06/16 09:01, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=363638
>
> caulier.gilles@gmail.com changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>           Resolution|---                         |FIXED
>               Status|UNCONFIRMED                 |RESOLVED
>
> --- Comment #4 from caulier.gilles@gmail.com ---
> It must miss libusb1. This is required to prevent conflict with opencv. See bug
> #268267 for details.
>
> In your configuration trace you must see something like that :
> ...
> -- Found gphoto2: -L/usr/lib64 -lgphoto2_port;-L/usr/lib64 -lgphoto2
> -lgphoto2_port -lm
> -- Found LibUSB1: /usr/lib64/libusb-1.0.so
> -- LibUSB1_FOUND        = TRUE
> -- LibUSB1_INCLUDE_DIRS = /usr/include/libusb-1.0
> -- LibUSB1_LIBRARIES    = /usr/lib64/libusb-1.0.so
> CMake Warning at core/CMakeLists.txt:351 (message):
>    libgphoto2 is found but libusb1 cannot be found on your system.
>    libgphoto2 support will be disabled.
> ...
>
> Gilles Caulier
>
Comment 6 caulier.gilles 2016-06-02 13:36:22 UTC
You have no libgphoto2 detection in cmake statements. This want mean that camek cache is not cleaned.

remove build sub dir and restart bootstrap.

Note : your bootstrap script is an older one (few hours i think), because it checkout translations. This must be disabled.

Gilles Caulier
Comment 7 Simon 2016-06-02 14:02:16 UTC
I always remove the build dir before rerunning the boostrap script and I 
know have made sure to run it on an entirely clean git clone. I removed 
the translation checkout from my custom bootstrap script, so know the 
only difference (certified by diff) to "bootstrap.linux" is
 >       -DDIGIKAMSC_COMPILE_LIBKIPI=ON \
 >       -DDIGIKAMSC_COMPILE_LIBKSANE=ON \
Do I need to set anything else such that these statements are visible?


On 02/06/16 15:36, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=363638
>
> --- Comment #6 from caulier.gilles@gmail.com ---
> You have no libgphoto2 detection in cmake statements. This want mean that camek
> cache is not cleaned.
>
> remove build sub dir and restart bootstrap.
>
> Note : your bootstrap script is an older one (few hours i think), because it
> checkout translations. This must be disabled.
>
> Gilles Caulier
>
Comment 8 caulier.gilles 2016-06-02 14:14:26 UTC
Git commit 591f8cdcdb5fe799f54aad9e48bbf3759a9d7b2e by Gilles Caulier.
Committed on 02/06/2016 at 14:13.
Pushed by cgilles into branch 'master'.

more debug statements for libgphoto2 detection

M  +6    -0    CMakeLists.txt

http://commits.kde.org/digikam/591f8cdcdb5fe799f54aad9e48bbf3759a9d7b2e
Comment 9 caulier.gilles 2016-06-02 14:15:19 UTC
there is no configuration option to set .

With last commit i print more debug statement about Gphoto2 detection.

Gilles Caulier
Comment 10 Simon 2016-06-02 15:07:19 UTC
Now there is this additional part about libgphoto:
-- Found Lqr-1: 
/usr/include/lqr-1;/usr/include/glib-2.0;/usr/lib/x86_64-linux-gnu/glib-2.0/include 

-- libgphoto2 found:
-- Checking for module 'lensfun'
--   Found lensfun, version 0.3.2.0
-- Found LensFun: /usr/include/lensfun (found version "0.3.2.0")
-- liblensfun: Found version 0.3.2.0 (required: 0.2.6.0)
The whole output is on http://pastebin.com/2QnNDJjr

On 02/06/16 16:15, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=363638
>
> --- Comment #9 from caulier.gilles@gmail.com ---
> there is no configuration option to set .
>
> With last commit i print more debug statement about Gphoto2 detection.
>
> Gilles Caulier
>
Comment 11 caulier.gilles 2016-06-02 15:17:30 UTC
The Gphoto2 string version detected by cmake is empty !

Your libgphoto2 is not detected or badly installed. Check your system.

You must see something like that now :
...
-- Found Lqr-1: /usr/include/lqr-1;/usr/include/glib-2.0;/usr/lib64/glib-2.0/include  
-- Found gphoto2: -L/usr/lib64 -lgphoto2_port;-L/usr/lib64 -lgphoto2 -lgphoto2_port -lm
-- libgphoto2 found: TRUE
-- Found LibUSB1: /usr/lib64/libusb-1.0.so  
-- LibUSB1_FOUND        = TRUE
-- LibUSB1_INCLUDE_DIRS = /usr/include/libusb-1.0
-- LibUSB1_LIBRARIES    = /usr/lib64/libusb-1.0.so
-- libusb1 found: TRUE
-- Libgphoto2 and libusb1 have been found.
-- libgphoto2 API version >= 2.5
-- libgphoto2 API version found:  2.5.7
-- checking for module 'lensfun'
...
Gilles Caulier
Comment 12 Simon 2016-06-02 21:32:31 UTC
Created attachment 99332 [details]
remove typos from FIndGphoto2.cmake and make it more verbose

I finally resolved this. The actual problem is that the debian package has the gphoto2-config executable in a dir outside of PATH. While searching for this cause I made updates to FIndGphoto2.cmake. There were variable names like "GHOTO..." and if it did not find the executables or the libraries there was no warning and the value FALSE was not assigned to GPHOTO2_FOUND.  So I added warnings plus this assignment. I had no idea about cmake before, so this might be not the way one does usually do this, but I hope its fine and can help.

Bug report is filed against the debian package regarding the mentioned problem. Thanks for the assistance.
Comment 13 caulier.gilles 2016-06-03 04:32:43 UTC
Git commit 401f077455ff1b4537262880b63458cac200c9c9 by Gilles Caulier.
Committed on 03/06/2016 at 04:30.
Pushed by cgilles into branch 'master'.

apply patch #99332 to polish gphoto2 detection

M  +30   -9    cmake/modules/FindGphoto2.cmake

http://commits.kde.org/digikam/401f077455ff1b4537262880b63458cac200c9c9
Comment 14 Simon 2016-06-03 07:13:14 UTC
Just for my own education, so only answer if you have time:
I have seen that you removed the return() calls in the else parts. My 
reason to use them was, that any further evaluation becomes useless (it 
already failed to find an essential part). It would be great if you 
could tell me the reason for not using return calls there.

On 03/06/16 06:32, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=363638
>
> --- Comment #13 from caulier.gilles@gmail.com ---
> Git commit 401f077455ff1b4537262880b63458cac200c9c9 by Gilles Caulier.
> Committed on 03/06/2016 at 04:30.
> Pushed by cgilles into branch 'master'.
>
> apply patch #99332 to polish gphoto2 detection
>
> M  +30   -9    cmake/modules/FindGphoto2.cmake
>
> http://commits.kde.org/digikam/401f077455ff1b4537262880b63458cac200c9c9
>
Comment 15 caulier.gilles 2016-06-03 07:28:20 UTC
I removed the return statements because in this case the gphoto cmake found flags is not stored in cmake cache, even if value is false. This must be always the case.

Check other cmake find script located at the same place. None use return statements.

Gilles Caulier