does not detect jack if provided by pipewire-jack-audio-connection-kit-devel

[jwaldmann]

[EDIT] not sure about the "bug" label. Still posting the issue in the hope that someone knows a work-around.

Environment

• SuperCollider version: 3.12.2-rc1
• Operating system: Fedora GNU/Linux
• Other details (Qt version, audio driver, etc.):

Package pipewire-jack-audio-connection-kit-devel-0.3.40-1.fc35.x86_64 is already installed.

$ pkgconf jack --cflags
-D_REENTRANT 
$ pkgconf jack --libs
-L/usr/lib64/pipewire-0.3/jack -ljack -ljacknet 
$ pkgconf jack --print-provides
jack = 1.9.17

related: https://bugzilla.redhat.com/show_bug.cgi?id=1966869

Steps to reproduce

$ cmake -DSC_QT=OFF -DCMAKE_INSTALL_PREFIX=/opt/supercollider/3.12.2-rc1   ../source-sc-3.12.2-rc1

Expected vs. actual behavior

expected: build from source succeeds

actual:

$ cmake -DSC_QT=OFF -DCMAKE_INSTALL_PREFIX=/opt/supercollider/3.12.2-rc1   ../source-sc-3.12.2-rc1
-- The C compiler identification is GNU 11.2.1
-- The CXX compiler identification is GNU 11.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- SuperCollider Version: 3.12.2-rc1
-- Building from branch HEAD, commit hash is 38b28f95e
-- Build type defaulting to "RelWithDebInfo"
-- Not compiling SC IDE, because it requires Qt but SC_QT is False
-- Found Pthreads: /usr/lib64/libpthread.a  
-- Using bundled boost
-- Using bundled yaml-cpp
-- HIDAPI components:
--     linux hidraw
-- libudev stable: 1
-- Found UDev: /usr/lib64/libudev.so
--    include: /usr/include
--     hidapi_parser
-- Building with HID support
-- Found Sndfile: /usr/lib64/libsndfile.so  
-- Found X11: /usr/include   
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found fftw3f: /lib64/libfftw3f.so
-- FFT library (scsynth): FFTW
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.8.0") 
-- Checking for module 'jack'
--   Found jack, version 1.9.17
CMake Error at server/scsynth/CMakeLists.txt:43 (message):
  Jack selected as audio API, but development files not found

[dvzrv]

This is more of a packaging problem on fedora's side in regards to the jack library files though.
libjack.so is expected to be located in the global lib namespace for FindJack.cmake to find it:

supercollider/cmake_modules/FindJack.cmake

Lines 43 to 56 in cea67fc

	find_library(JACK_LIBRARY
	NAMES
	jack
	PATHS
	${_JACK_LIBDIR}
	/usr/lib
	/usr/local/lib
	/opt/local/lib
	/sw/lib
	)
	if (JACK_LIBRARY)
	set(JACK_FOUND TRUE)
	endif (JACK_LIBRARY)

[dvzrv]

That being said: You can modify the find_library() call to include your custom libjack.so location /usr/lib64/pipewire-0.3/jack.

[jwaldmann]

Thanks, will try this. - Is SC not using the output of pkgconf jack --libs? Because that's where Fedora reports its custom location.

[dvzrv]

Is SC not using the output of pkgconf jack --libs?

No. Pkgconfig integration has historically been a bit weird with cmake (although it has improved over the past years), which is why the custom FindJack.cmake exists (but probably shouldn't anymore by now).

As a sidenote: There are also quite a few projects that do only rely on plain makefiles and attempt to link against libjack.so directly (using -ljack), which would also break in this context if not supplying an additional search dir for the linker (e.g. -L/usr/lib64/pipewire-0.3/jack).

As background information: Pipewire's jack implementation is supposed to be able to replace jack properly, therefore it should also provide the jack libraries at the appropriate location. On Arch Linux we are also not there yet (and therefore do not provide or support pipewire providing the development files for jack). As soon as https://github.com/jackaudio/jack-example-tools has gotten a release (most likely this month), I plan on changing that though unless upstream thinks this is a bad idea.

[dvzrv]

which is why the custom FindJack.cmake exists (but probably shouldn't anymore by now).

I think I can provide a PR to remove the current implementation and replace it with the builtin FindPkgConfig based implementation (as supercollider only supports cmake >= 3.12.0 anyways).

[dvzrv]

@jwaldmann can you check whether #5680 improves this for you?

[jwaldmann]

configuration looks good:

ver=dvrzv
cmake -DSC_QT=OFF -DCMAKE_INSTALL_PREFIX=/opt/supercollider/$ver   ../source-sc-$ver
...
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.8.0") 
-- Checking for module 'jack'
--   Found jack, version 1.9.17
-- Audio API (scsynth): jack
...

compilation seems fine, linking gives an error

JOBS=-j8
cmake --build . --config Release $JOBS
...
[ 74%] Linking CXX executable scsynth
/usr/bin/ld: cannot find -ljack
/usr/bin/ld: cannot find -ljacknet
collect2: error: ld returned 1 exit status
gmake[2]: *** [server/scsynth/CMakeFiles/scsynth.dir/build.make:123: server/scsynth/scsynth] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:3138: server/scsynth/CMakeFiles/scsynth.dir/all] Error 2

The libraries are present:

$ ls /usr/lib64/pipewire-0.3/jack/
libjacknet.so    libjacknet.so.0.340.0  libjackserver.so.0        libjack.so    libjack.so.0.340.0
libjacknet.so.0  libjackserver.so       libjackserver.so.0.340.0  libjack.so.0

The command that was used for linking is

$ cmake  --build . --config Release  -v
...
cd /home/waldmann/software/music/supercollider/build-sc-dvzrv/server/scsynth && /usr/bin/cmake -E cmake_link_script CMakeFiles/scsynth.dir/link.txt --verbose=1
/usr/bin/c++  -msse -mfpmath=sse -msse2 -O2 -g -DNDEBUG CMakeFiles/scsynth.dir/scsynth_main.cpp.o CMakeFiles/scsynth.dir/__/__/common/SC_ServerBootDelayWarning.cpp.o -o scsynth  libscsynth.a /usr/lib64/libpthread.a ../../external_libraries/libtlsf.a /usr/lib64/libdl.a /usr/lib64/libsndfile.so /usr/lib64/libavahi-common.so /usr/lib64/libavahi-client.so -ljack -ljacknet ../../external_libraries/libboost_system_lib.a ../../external_libraries/libboost_filesystem_lib.a /lib64/libfftw3f.so -lrt 
/usr/bin/ld: cannot find -ljack
/usr/bin/ld: cannot find -ljacknet
collect2: error: ld returned 1 exit status

[dvzrv]

compilation seems fine, linking gives an error

Ah, my bad. Should have used JACK_LINK_LIBRARIES instead of JACK_LIBRARIES.
Please try again with the current HEAD of that branch.

[jwaldmann]

Works!

[jwaldmann]

thank you for handling this quickly, and for explaining related issues.

[dvzrv]

thank you for handling this quickly, and for explaining related issues.

You're welcome! Always happy to remove old code 😆

[patrickdupuis]

I've been having issues building SC against the Piprewire JACK headers on Fedora 35. I just tested #5680 and was able to run cmake and successfully build SC.

Previously, I had used this workaround:
$ cmake -DAUDIOAPI=jack -DJACK_LIBRARY=/usr/lib64/pipewire-0.3/jack/libjack.so ..

[jwaldmann]

ping. This didn't make it into the main branch?

[dyfer]

Hello @jwaldmann
This is an issue, not a PR, so it can't "make it" into a branch. The linked PR would (listed close to the top on the right) but it hasn't yet, waiting for a follow up from its author.

[dvzrv]

@jwaldmann yeah, I lost track of this. There was a small change still to be made (I think that is now done satisfactory) and should be good to go though!

[jwaldmann]

much appreciated. I can cherry-pick your commit 7297605 onto sc-3.13.0-rc1 and that seems to work but it's a bit of a hassle.