Tethering at macOS not working - no cameras/ports found

[stfrasch]

Describe the bug

Tethered shooting to darktable is from Darktable Version 4.4.x on no longer possible at MacOS. darktable -d camctl shows following output

6,9130 [camera_control] creating new context 0x600001d34a80 6,9172 [camera_control] loaded 0 camera drivers. 11,1384 [camera_control] loaded 0 port drivers. 11,1387 [camera_control] 0 cameras connected

Looks like libgphoto2 is not able to find camlibs and ports

After short debugging, I was able to locate the problem. Paths to 'CAMLIBS' and 'IOLIBS' at File 'osx.mm' are set wrong for newer gphoto2 Libs. Libgphoto2 has now the version number inside the path. Old: CAMLIBS are directly at 'libgephoto2' New: CAMLIBS at 'libgphoto2//'

Same problem for 'libgphoto2_port' After adapting the paths with my current version numbers + rebuild darktable, tethering works fine!

Output now: 2,2457 [camera_control] creating new context 0x600002ba2300 2,3334 [camera_control] loaded 2668 camera drivers. 5,9743 [camera_control] loaded 6 port drivers. 6,0218 [camera_control] 1 cameras connected 6,0218 [camera_control] found new Sony ILCE-7M2 (Control) on port usb:020,052

=> Tethering is now working fine!

The hardcoded version numbers at my quick test is not a good solution - needs to be dynamic in my point of view.

Steps to reproduce

Just start darktable with command ./darktable -d camctl and see output No connected camera needed - camera drivers and port drivers needs to be detected

Expected behavior

Working Tethering - Camera detected

Logfile | Screenshot | Screencast

Changed paths at osx.mm:

 {
      gchar* lib_path = g_build_filename(res_path, "lib", NULL);
      {
        gchar* io_path = g_build_filename(lib_path, "libgphoto2_port/0.12.2", NULL);
        g_setenv("IOLIBS", io_path, TRUE);
        g_free(io_path);
      }
      {
        gchar* cam_path = g_build_filename(lib_path, "libgphoto2/2.5.31", NULL);
        g_setenv("CAMLIBS", cam_path, TRUE);
        g_free(cam_path);
      }

Commit

No response

Where did you install darktable from?

darktable.org

darktable version

4.4.2

What OS are you using?

Mac

What is the version of your OS?

MacOS Monterey (Intel)

Describe your system?

iMAC 2017 Intel running macOS Monterey Testbuild was done with Homebrew

Are you using OpenCL GPU in darktable?

None

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[MStraeten]

at least no generic macOS issue since using a macports based build is fine. maybe something homebrew related

[zisoft]

The package content built with homebrew looks like this:

How does that look with a macports build?

[stfrasch]

Issue can be seen as well with the official build from darktable.org! I've done only the debug builds with Homebrew. Library package structure looks like the same at official build as posted from zisoft. Only version number is here 2.5.30

stefan@iMac-von-Stefan 2.5.30 % ls
ax203.so    directory.so    kodak_dc240.so  ptp2.so     sq905.so
canon.so    docupen.so  lumix.so    ricoh_g3.so st2205.so
digigr8.so  jl2005a.so  mars.so     sierra.so   topfield.so
dimagev.so  jl2005c.so  pentax.so   sonix.so    tp6801.so
stefan@iMac-von-Stefan 2.5.30 % pwd
/Applications/darktable.app/Contents/Resources/lib/libgphoto2/2.5.30
stefan@iMac-von-Stefan 2.5.30 % 

Thank you for having a look!

[zisoft]

While your solution may work it is generally a bad idea to put version numbers in the code. This will fail again on the next update of gphoto.

[stfrasch]

@zisoft Absolutely agreed, as I've written in the last line of the bug description, it needs to be dynamic ;-) I've just done it to get a short confirmation, that the correct path will solve the issue.

[zisoft]

I think a better way for setting env variables for the bundle is to put them in Info.plist. I will think about that.

[stfrasch]

Thank you for taking care at the MacOS Version of darktable.

[MStraeten]

macports: but also:

but according to latest port file it's 2.5.31 ...

[stfrasch]

Maybe interesting... Had a look at the ARM Package, and yes it shows the structure @MStraeten showed. Looks like only a Issue for the Intel platform. Structure of both (official) 4.4.2 Images from darktable.org

[MStraeten]

since I built the official arm64 package I’d wonder if it would be different ;) But my x86-64 builds done with macports are having the same structure… See https://discuss.pixls.us/t/macos-10-14-darktable-4-4-x-release-build/38316 or https://discuss.pixls.us/t/current-osx-build/13213/722

[stfrasch]

OK understood. Are the (official) Intel builds done out of Homebrew and not like the ARM64 with macports? If the macports build for INTEL will be OK, than this could 'solve' at least the broken official packages for INTEL. I guess most of the users will not try to compile darktable themselves with Homebrew.

[MStraeten]

since the github macos runner depends on homebrew it's quite important to have a solution for homebrew ;)

[zisoft]

I have a fix

[zisoft]

@stfrasch: The official x86_64 builds are done on github runners with homebrew. The long term goal is to build everything on github but arm64 runners are still not available on github.

[stfrasch]

@zisoft Great! Thanks for the explanation :-)

[zisoft]

It is not the directory structure of the libraries in the bundle causing problems here. It is the awkward way to set environment variables during runtime in osx.mm.

The official way to set env variables for app bundles is to place them in Info.plist but that requires changes in the build processes for both package managers macports and homebrew.