Build script improvements #34
Conversation
Ensure that these scripts are executed by the standard 'sh', rather than whatever your current shell happens to be.
If pkg-config is installed, then libsndfile's configure will try to use pkg-config to check whether the optional dependencies (flac, ogg, vorbis, opus, mpg123) are present. (It will conclude that the packages are present because the appropriate *_CFLAGS and *_LIBS are set.) If pkg-config isn't installed, then --enable-external-libs and --enable-mpeg must be set explicitly in order to use these packages.
Remove the old workflow using CentOS 7 (which is unsupported and broken) and replace it with one using a newer (glibc 2.28 based) container from pypa.
|
I don't really know what I'm doing, but I've tried to update the workflow to use the "manylinux_2_28" container from https://github.com/pypa/manylinux in place of the old CentOS 7 one. Let's see if it works? |
Note that GitHub's "macos-13" runners are x86-64 whereas "macos-14" runners are arm64.
|
It looks like the manylinux_2_28 build is okay. But it sounds like It probably makes sense to switch Intel builds to use It looks like there are some other build problems on Windows, unfortunately. |
The libvorbis configure script will try multiple methods to find the libogg headers and library. Using the pkg-config variables is the newer and probably-more-stable method.
|
Problem in libvorbis: xiph/vorbis#107 |
Instead of using an arm64 native compiler and everything else running inside an emulator, use the aarch64-linux-gnu cross compiler provided by Debian 10 (glibc 2.28).
In libsndfile 1.2.1 and 1.2.2, the spelling of "mpg123" in the cmake variable names was changed to lowercase.
|
So, this pull request has expanded greatly in scope. The Additionally, I've added a workaround for the vorbis issue. Meanwhile, on the Linux side: I switched the workflow to building the arm64 library using a cross-compiler on Debian 10 (amd64), rather than running a native compiler on an emulated CPU. This should be much faster! I haven't yet tested the resulting binary, and it should be checked (using Something is still broken in Windows and I have not begun to dig into that. My personal inclination would be to use cross-compilation there too. |
|
Wow, that's an extensive set of changes! Thank you so much for looking into this! |
|
Regrettably, cross-compilation doesn't work for Windows, as Python is built with the MSVC compiler, and all linked libraries are required to use the MSVC compiler as well. Clang and GCC can be made to work in some narrow circumstances, but it's just a recipe for headaches. I'd guess that, either, there's a bug in the VCPKG build file that will resort itself, or that something about the "-custom" triplet is no longer appropriate. |
|
Do you want to take a stab at the Windows compilation issue as well? No problem at all if not. I'm absolutely grateful for what you have done and achieved so far! |
A few small changes to make the build scripts behave more predictably.
set the script interpreter
if any command fails, the script should fail
don't assume pkg-config is installed