soxr @0.1.3_0 build problem

[ith140 (Ian Hoffman)]

Failure to build during installation as dependency of ffmpeg6 port. Build reports missing omp.h but I have the libomp package installed on my system (and tried with +top_level variant) but it still fails.

[ryandesign (Ryan Carsten Schmidt)]

There are several build attempts in your log. All but the last failed due to undefined symbols; the last failed because omp.h was not found. Just to make sure we're troubleshooting the correct issue, could you please sudo port clean soxr, try again, and attach the fresh main.log?

[ith140 (Ian Hoffman)]

fresh build log

[ith140 (Ian Hoffman)]

Sorry I was trying a couple things to get it to build but they all failed. I've attached a fresh build log.

[zzanderr]

For me, soxr build fails when libomp is built with the +top_level variant, but succeeds when the variant is turned off.

(MacBook Pro M2 Max, MacOS 14.1 Sonoma)

[kencu (Ken)]

when libomp is built with the +top_level variant, then openmp will be opportunistically found by soxr.

However, Xcode clang doesn't know much about openmp, and although the -fopenmp flag is added to the build, the library is not added... you can manually add the openmp library to the build to fix that, inelegant, but works.

The opensource clang knows what to do with openmp -- building soxr with macports-clang-17 works, even if libopenmp is installed with the +top_level variant, as the library is added.

All of this requires attention to set up deterministically for builds that might or might not want openmp. If it is decided that soxr always should be built with openmp, then the build can be set up that way, and suitable compilers required.

MacPorts has not fully explored how to do this correctly as yet. Some type of unifying approach for comprehensive openmp support is needed, where libraries can indicate to ports that request them that openmp is needed, etc.

If you use libopenmp with the +top_level variant, it would not be surprising to run into similar issues with other ports, possibly quite frequently.