Unable to build with libsndfile headers from the submodule

[oleg68]

oleg@oleg2:~/my-projects/loopauditioner/LoopAuditioneer/build$ make
[  4%] Building CXX object src/CMakeFiles/LoopAuditioneer.dir/LoopAuditioneer.cpp.o
In file included from /home/oleg/my-projects/loopauditioner/LoopAuditioneer/src/MyFrame.h:28,
                 from /home/oleg/my-projects/loopauditioner/LoopAuditioneer/src/LoopAuditioneer.h:26,
                 from /home/oleg/my-projects/loopauditioner/LoopAuditioneer/src/LoopAuditioneer.cpp:22:
/home/oleg/my-projects/loopauditioner/LoopAuditioneer/src/FileHandling.h:25:10: fatal error: sndfile.hh: No such file or directory
   25 | #include "sndfile.hh"
      |          ^~~~~~~~~~~~
compilation terminated.
make[2]: *** [src/CMakeFiles/LoopAuditioneer.dir/build.make:76: src/CMakeFiles/LoopAuditioneer.dir/LoopAuditioneer.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:98: src/CMakeFiles/LoopAuditioneer.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

The sndfile.hh file presents in the submodules/libsndfile/include directory but seems it is not passed to the c++ compiler as include directory.

[larspalo]

The header file should have been moved to an include directory within in the build directory if everything worked as it should. Are you sure that libsndfile built correctly during the first cmake run?

You should have seen a line like

Local libsndfile was successfully built!

and the header file should be within the build/include directory if everything worked as it should. If not something failed during the initial cmake run.

[oleg68]

Are you sure that libsndfile built correctly during the first cmake run?

These are the logs of cmake and of make runs: logs.zip

You should have seen a line like

Local libsndfile was successfully built!

I cannot see this in my cmake.log. Usually anything is build during the make phase, not during the cmake one.

[larspalo]

@oleg68 From your cmake.log it seems that neither libsndfile nor RtAudio is built correctly. Only libsamplerate is correctly built of the external libraries.

Both failures mention

make: *** No rule to make target 'src/test_endswap.c', needed by 'all'. Stop.

The RtAudio also mention

checking for jack_client_open in -ljack... no
configure: error: JACK support requires the jack library!

I'm not sure, but some dependencies might be missing. What distribution are you building on?

[larspalo]

Also the version mentioned is 0.10.0 in the logs. I don't think that too much really should have changed but maybe test with the most recent source.

Regarding the dependencies, things like autoconf, autogen, automake and autoconf-archive are necessary on debian based distros. Package naming might vary for others though...

[oleg68]

@larspalo Thank you. After updating to the latest LA version installing autogen and autoconf-archive cmake started building libsndfile. But it cannot still build RtAudio:

CMake Error at CMakeLists.txt:147 (message):
  Local RtAudio couldn't be built! Build procedure will fail, aborting!

cmake.log.zip

[larspalo]

@oleg68 Make sure you have the equivalents to libjack-dev, libasound2-dev and libpulse-dev on the system.

[oleg68]

@larspalo These are all installed. Moreover I can build RtAudio as a submodule of GrandOrgue.

How to get a log of building RtAudio during cmake?

[larspalo]

How to get a log of building RtAudio during cmake?

The building of all external libraries for LoopAuditioneer happen at the first cmake invocation, and the external libraries are never called to build after that if the necessary library already is found "installed" in the build path. If something fails during that first cmake phase I think you should have a .log file in the /tmp directory to check. I hope that will help you track down what causes the problem. I remember having quite a lot of issues building everything the first time when I updated all the versions. Now, the automated Github builds seem to be working ok at the moment.

The commit reference to RtAudio I used for the submodule in LoopAuditioneer might be somewhat later than what GO use, so somethings might have changed between them. Most likely it's some pre configure step that's not performed correctly, or that some dependency library is not as expected.