#1503 Release build with no libsndfile!

[D. Michael McIntyre]

While diagnosing [#1500], I created a release build in the build/ directory, doing a standard cmake .. with no options.

This was a clean build in a fresh new directory. It compiled without libsndfile! Contrast to my (usual) debug build:

$ ldd release/rosegarden|grep snd
$ ldd debug/rosegarden|grep snd
libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile(...)

Having experienced that, I did a clean debug build in a fresh new directory, just in case my original build was still working due to some legacy.

$ ldd tapioca/rosegarden|grep snd
libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile(...)

The debug build worked fine. Just to make really, really sure I'm not just stupid, I repeated the experiment with a new release build directory too.

I got the same result, and believe it or not, I can't import audio files with this release build!

See bug [#1494].

[David Faure]

Interesting, it was working in my last release build (November)

ldd ./rosegarden | grep snd
libsndfile.so.1 => /usr/lib64/libsndfile.so.1 (0x00007f7e1334c000)

Updating.... removing CMakeCache.txt, re-running cmake (with build type Release) and make....

Same result => can't reproduce the bug here.

Do you see SNDFILE under "-- The following features have been enabled:" at cmake time?

[Yves Guillemot]

I see libsndfile in both release and debug build:

[yves@localhost RELEASE]$ ldd ./rosegarden | grep snd
        libsndfile.so.1 => /lib64/libsndfile.so.1 (0x00007f8a6dc21000)

[yves@localhost DEBUG]$ ldd ./rosegarden | grep snd
        libsndfile.so.1 => /lib64/libsndfile.so.1 (0x00007fac040e2000)

Nevertheless, I can load a .wav file without any problem with the debug build but I get an error when I try to load the same file with the release build: "Failed to add audio file. Bad sound file xxx.wav: Failed to convert or resample audio file on import".

sndfile is enabled in cmake:

-- Found X11: /usr/lib64/libX11.so
-- checking for module 'liblo>=0.7'
--   found liblo, version 0.28
-- checking for module 'lrdf>=0.2'
--   found lrdf, version 0.5.0
-- checking for module 'fftw3f>=3.0.0'
--   found fftw3f, version 3.3.4
-- checking for module 'samplerate>=0.1.2'
--   found samplerate, version 0.1.8
-- checking for module 'sndfile>=1.0.16'
--   found sndfile, version 1.0.25
-- checking for module 'jack'
--   found jack, version 1.9.10
-- 
-- The following features have been enabled:


 * ALSA , Alsa library (Advanced Linux Sound Architecture), used for MIDI support
 * SNDFILE , Better support for WAV files
 * JACK , Library for accessing the JACK server (http://jackaudio.org).

-- The following REQUIRED packages have been found:


 * Qt4
 * PkgConfig
 * ZLIB
 * X11

-- The following features have been disabled:


 * LIRCCLIENT , The LIRC client library, for remote control support

-- Not building unit tests, using a static library for rosegarden

[D. Michael McIntyre]

~~~~
-- The following features have been enabled:
...

• SNDFILE , Better support for WAV files
  ~~~~
  Compiled again, and no libsndfile. Right after we did the first public release with the new build system, a user reported this issue, and I could not repeat it at that time. We ended up laying the blame on his distro. Falsely, it appears.

To my annoyance, I can't find a test build from the 15.12 release. I built the tarball from scratch, and got the same result I've been getting consistently since I noticed this problem. Sndfile is supposedly enabled, but it isn't compiled in, and related features are broken. That rules out the patches I accepted a little while back.

[Yves Guillemot]

Here, when using a debug buid, AudioWriteStreamBuilder<wavfilewritestream> ctor is called at initalization when static object wavbuilder is created (in WavFileWriteStream.cpp).</wavfilewritestream>

When using a release build, this ctor is no more called (wavbuilder is not initalized).

That's the cause of the problem I encounter as usable audio file types are defined at this specific moment.

I don't know why libsndfile is linked or not depending of the distro but it's probably a secondary question.

[David Faure]

I think I know what the problem is, then.
The difference between debug and release, in rosegarden (unlike other projects) is that debug build uses shared libraries, while release build uses static libraries.
Global objects in static libraries do NOT get initialized.
See the description of Q_INIT_RESOURCE in the Qt documentation another example of global objects which suffer from the fact that they don't get initialized in static libs.
I recommend doing something similar, i.e. calling an explicit initialization function (or creating the object) in main, rather than relying on constructors of global objects being called.

The reason why libsndfile is then removed from the linked libs is probably the --as-needed flag of the linker (which some distros default to, but others don't) : when this flag is set, and nothing uses libsndfile, then it gets removed from the dependencies. But that's just a consequence, not the cause.

[Yves Guillemot]

That make sense.
The objects are now initialized from main in rev. 14518.
All is now working fine here whatever the build is.

[D. Michael McIntyre]

I find this fascinating, and oddly satisfying, sort of like a mystery novel with a really interesting twist at the end. Thanks for puzzling this one out, David! Thanks, Yves, for coding up a solution!

[D. Michael McIntyre]

And there we go. This solution passes all the tests I can think to throw at it.