libsndfile @1.0.31: move to CMAKE has made the library compatibility version go backwards from 2.0.0 to 1.0.0, breaking everything that links with it

[kencu (Ken)]

$ port -v installed libsndfile
The following ports are currently installed:
  libsndfile @1.0.28_1+universal (active) platform='darwin 10' archs='i386 x86_64' date='2018-06-02T09:35:55-0700'
  libsndfile @1.0.31_0+universal platform='darwin 10' archs='i386 x86_64' date='2021-05-15T01:52:52-0700'

$ otool -L /opt/local/lib/libsndfile.1.dylib
/opt/local/lib/libsndfile.1.dylib:
	/opt/local/lib/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.28.0)
	/opt/local/lib/libFLAC.8.dylib (compatibility version 12.0.0, current version 12.0.0)
	/opt/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.3.0)
	/opt/local/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.8.0)
	/opt/local/lib/libvorbisenc.2.dylib (compatibility version 3.0.0, current version 3.11.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

$ sudo port activate libsndfile
The following versions of libsndfile are currently installed:
 1) libsndfile @1.0.28_1+universal (active)
 2) libsndfile @1.0.31_0+universal
Enter a number to select an option: 2
--->  Deactivating libsndfile @1.0.28_1+universal
--->  Cleaning libsndfile
--->  Activating libsndfile @1.0.31_0+universal

$ otool -L /opt/local/lib/libsndfile.1.dylib
/opt/local/lib/libsndfile.1.dylib:
	/opt/local/lib/libsndfile.1.dylib (compatibility version 1.0.0, current version 1.0.31)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
	/opt/local/lib/libvorbisenc.2.dylib (compatibility version 3.0.0, current version 3.12.0)
	/opt/local/lib/libFLAC.8.dylib (compatibility version 12.0.0, current version 12.0.0)
	/opt/local/lib/libopus.0.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.9.0)
	/opt/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.4.0)

reverting to 1.0.28_1 fixes everything.

[kencu (Ken)]

Otherwise, this:

$ sudo port -v rev-upgrade
--->  Scanning binaries for linking errors
Incompatible library version: /opt/local/bin/sndfile-resample requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /Applications/MacPorts/Audacity.app/Contents/MacOS/Audacity requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/bin/twolame requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/lib/audacious/Input/sndfile.bundle requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/bin/fluidsynth requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/bin/fluidsynth requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/lib/libfluidsynth.2.1.2.dylib requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/lib/libfluidsynth.2.1.2.dylib requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/bin/fizmo-ncursesw requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/bin/fizmo-sdl2 requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/bin/rubberband requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/lib/octave/6.2.0/oct/x86_64-apple-darwin10.x.x/audioread.oct requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/lib/gstreamer-1.0/libgstsndfile.so requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
Incompatible library version: /opt/local/bin/jack_rec requires version 2.0.0 or later, but /opt/local/lib/libsndfile.1.dylib provides version 1.0.0
--->  Found 14 broken files, matching files to ports     
--->  Found 10 broken ports, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
 fizmo @0.8.5
 fluidsynth @2.0.5+universal
 libsamplerate @0.1.9
 jack @1.9.18
 rubberband @1.9.1
 twolame @0.4.0
 audacity @2.2.2
 audacious-plugins @3.10.1+aac+cdaudio+console+cue+dbus+ffmpeg+filewriter+flac+full+gtk2+lame+lastfm+lirc+midi+mms+modplug+mp3+notifications+opengl+osd+osd_composite+sdl1+sndfile+transform+wavpack
 gstreamer1-gst-plugins-bad @1.16.2+x11
 octave @6.2.0+accelerate+app+gfortran+graphicsmagick+qt4+sound+sundials

[kode54 (Christopher Snowhill)]

It didn't even have working FLAC, Vorbis, or Opus support before.

[kode54 (Christopher Snowhill)]

I tell you what, let's just revert this forever, I won't be using MacPorts to built for my project anyway, since I need to supply minimum SDK version arguments so it builds for as low as 10.13 anyway.

[kencu (Ken)]

It looks like the compatibility version was just wrong before; now we have all this software built against libsndfile.1.dylib with a compatibility version of 2.0.0 that we have to deal with.

perhaps someone might be able to fix up the compatibility version to be as it was before (2.0.0) and then see where we wind up.

The rule with compat versions is they can never decrease, otherwise this wreckage happens.

[kode54 (Christopher Snowhill)]

Blame upstream for that. I didn't change anything other than move to a different source base. I guess we can just stick with 1.0.28 forever, and patch the external library tests so they actually compile.

[kencu (Ken)]

CMake is a bit ugly here. It is not trivial to change the compatibility version to 2.0.0 and leave the filename as libsndfile.1.dylib. cmake fights you.

I stumbled across ​this and thought it might work:

configure.args-append -DMACHO_COMPATIBILITY_VERSION=\"2.0.0\"

but in that way that the obvious is never obvious, it did not.

So I'm just going to hold back my installs at 1.0.28 with the compatibility version of 2.0.0 and the filename of libsndfile.1.dylib until such time as we either fix this, or revbump absolutely everything that links against libsoundfile to pick up the new details, which is all this:

$ port echo depends:libsndfile
aubio                           
audacious-plugins               
audacity                        
audacity-devel                  
blender                         
chuck                           
csound                          
denemo                          
dsd                             
faust                           
faust-devel                     
faustlive-devel                 
fizmo                           
fldigi                          
fluidsynth                      
freedv-gui                      
gstreamer010-gst-plugins-bad    
hydrogen                        
Io                              
jack                            
libgig                          
libkdegames                     
libsamplerate                   
libVLC2                         
lmms                            
ltc-tools                       
mednafen                        
minimodem                       
octave                          
pHash                           
pulseaudio                      
pure-audio                      
py27-pyepl                      
py27-scikits-audiolab           
py37-soundfile                  
py38-soundfile                  
py39-soundfile                  
qtads                           
rubberband                      
scummvm                         
scummvm-devel                   
sfml                            
shenidam                        
simage                          
sox                             
twolame                         
VLC2                            
xournalpp                       
freac                           

[jmroot (Joshua Root)]

See the comments on ​https://github.com/macports/macports-ports/commit/a6e6dff7ad6309b4131772d20f7dae945b142278. Upstream confirmed that their cmake build is incorrect in setting a different compatibility version, and that "Autotools is the primary and recommended build toolchain."

[kode54 (Christopher Snowhill)]

Fine, they fixed it:

​https://github.com/libsndfile/libsndfile/pull/743

But switch back to autotools, by all means. I couldn't even get autotools to build a universal version, because it stupidly expects autogen to be built universal, which it doesn' support.

So I shall continue manually building anything I actually depend on, since I also haven't figured out how to make MacPorts build for anything older than my current OS version. I'm building for distribution, I refuse to make my users pick a particular package manager and install all my deps with it.

[kencu (Ken)]

Yes, I agree with you that it's good that MacPorts' users have the ability to detect these (often minor, but irritating) flaws and send pointers to upstream on how to fix and/or improve their software. I'm glad we can help out.

Re: the universal version, I don't know -- I have had libsndfile built universal for years:

$ ls -la libsndfile.1.dylib
-rwxr-xr-x  1 root  admin  947416  2 Jun  2018 libsndfile.1.dylib

$ file libsndfile.1.dylib
libsndfile.1.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [i386:Mach-O dynamically linked shared library i386]
libsndfile.1.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
libsndfile.1.dylib (for architecture i386):	Mach-O dynamically linked shared library i386

so I didn't realize anyone was having trouble trying to build it that way.

[kencu (Ken)]

Regarding your need to build for an older OS version -- MacPorts has some ability in that regard (you can set an older deployment target in macports.conf, and it will be honoured by most software builds) but it's true that this functionality is not extensively tested and I know for a fact that certain builds, like libvpx, just don't pay attention to that and do their own thing. But it can work for many such situations.

you might be interested in a system that one of MacPorts' early architects devised for a big, complicated build of Xquartz using many deps, patch support, and custom deployment targets. It's here <​https://github.com/XQuartz/XQuartz/blob/master/compile.sh> in that repo that uses it.

Very clever and well done I thought, and it looks very adaptable to custom setups and needs.

Best of luck!

[kencu (Ken)]

And regarding the universal autogen issue: MacPorts has a "flaw" that is kinda hard to see how to work around.

If you have no ports installed, and you type something like sudo port -v install libsndfile +universal then MacPorts will pass that +universal to all the build deps when they are being installed. For certain things, like gmake and cmake and similar, that is just not needed, but MacPorts is not able to understand that you don't need it +universal as it's just a build tool.

However, if you already have installed gmake or cmake or whatever, non-universal, and then you type sudo port -v install libsndfile +universal, MacPorts is smart enough to (usually) realize that you don't need those things built universal, and it will (usually) not try to make you rebuild them universal.

I think this is just hard to fix. We have suggested certain fixes, like adding depends-skip-archcheck to the cmake PortGroup, etc, but so far these suggestions have been rejected as incomplete.

So -- I guess you just have to know that, eventually.

[kode54 (Christopher Snowhill)]

Yeah, revert the CMake and Github change. There are release tarballs on the new home page that are pre-bootstrapped. I don't know how well they support detecting the dependencies, though. Possibly better than 1.0.28 did.

[kencu (Ken)]

this quick fix gets the cmake situation under control.

not committing is as we're going back to autotools I understand

​https://github.com/macports/macports-ports/pull/11077/commits/c04d7382b8cc34041f775f847c6d7d30187af7dd

[JDLH (Jim DeLaHunt)]

I suspect that change to @1.0.31_1 in commit fcf6712 might have triggered #62969.