openal-soft: opportunistic use of libsndfile

[atalkingegg]

port install openal-soft works fine.
port install wine asks for a "+universal" ?? variant of openal-soft (if available, which it is), which adds a -arch i386 compiler flag, which creates warnings ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS), but when linking creates the error Undefined symbols for architecture i386:, (_sf_close, sf_command, _sf_open, _sf_readf_float).

macOS 10.13.6 17G14042
Xcode 10.1 10B

port -s install openal-soft works.
port -s install openal-soft +universal fails.

Suggested fix: remove broken +universal from openal-soft on High Sierra, or track down missing i386 linked file.

[jmroot (Joshua Root)]

Please attach the log.

[ryandesign (Ryan Carsten Schmidt)]

Yes, the old version of wine that we have in MacPorts is a 32-bit program so installing wine on a 64-bit computer will require all dependencies to be installed universal.

Yes, support for 32-bit programs is deprecated in macOS High Sierra, and was removed in macOS Catalina. The warning Apple prints when trying to build for i386 is just reminding you of that.

Yes, we will need to see the log file to begin to analyze what went wrong here.

[atalkingegg]

I'm not sure what changed, but today trying the port install openal-soft +universal command and it was able to pull down a proper build. I tried uninstalling it and doing a port -s install openal-soft +universal and it also worked. If it ain't broke, don't fix it.

Here's the tail end of what it was doing yesterday.

make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_openal-soft/openal-soft/work/build'
/Applications/Xcode_10.1.app/Contents/Developer/usr/bin/make  -f CMakeFiles/makemhr.dir/build.make CMakeFiles/makemhr.dir/build
Undefined symbols for architecture i386:
  "_sf_close", referenced from:
      _main in uhjencoder.cpp.o
  "_sf_command", referenced from:
      _main in uhjencoder.cpp.o
  "_sf_error", referenced from:
      _main in uhjencoder.cpp.o
  "_sf_open", referenced from:
      _main in uhjencoder.cpp.o
  "_sf_readf_float", referenced from:
      _main in uhjencoder.cpp.o
  "_sf_writef_float", referenced from:
      _main in uhjencoder.cpp.o
Undefined symbols for architecture i386:
ld: symbol(s) not found for architecture i386
  "_sf_close", referenced from:
      _main in uhjdecoder.cpp.o
  "_sf_command", referenced from:
      _main in uhjdecoder.cpp.o
  "_sf_open", referenced from:
      _main in uhjdecoder.cpp.o
  "_sf_readf_float", referenced from:
      _main in uhjdecoder.cpp.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Go ahead and close this ticket. Thanks!

[ryandesign (Ryan Carsten Schmidt)]

The _sf_ symbols are from libsndfile. openal-soft doesn't declare a dependency on libsndfile, but it looks like openal-soft tries to use libsndfile anyway if you already had it installed. That would be a bug that I would need to fix. The undefined symbols are being encountered when compiling uhjencoder.cpp and uhjdecoder.cpp and those files only get compiled ​when libsndfile is found.

If you already had libsndfile installed for x86_64 only but were trying to build openal-soft universal (for both x86_64 and i386), that would explain the message "Undefined symbols for architecture i386" in regard to these symbols.

We usually want to see the entire main.log to analyze a problem. It might show us something like "libsndfile found" that would confirm such a diagnosis. In this case, though, I'm confident I've identified what happened so a log is no longer necessary.

What happened after you filed this ticket is that Josh forced a build of wine's dependencies with the universal variant on our macOS 10.13 build machine to see if it encountered the same problem you did. It didn't, and so a binary archive of openal-soft with the universal variant became available. Binary archives are normally only produced with a port's default set of variants, which does not normally include the universal variant.

I'm not sure why a from-source build now succeeds for you as well unless you either uninstalled libsndfile or installed libsndfile with the universal variant.

[ryandesign (Ryan Carsten Schmidt)]

If libsndfile is found, openal-soft builds uhjencoder and uhjdecoder but it doesn't install them nor do they appear to be used at build time. I ​asked upstream why those programs aren't installed. They said they aren't useful for most users and their names, being generic and not specific to OpenAL, might conflict with other software (though they don't appear to in MacPorts at this time). They also advised how to prevent libsndfile from being found, so I'll make that change in the Portfile soon.