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.
