[libmad] update to 0.16.4

[generic-pers0n]

Switches libmad to Tenacity's maintained version, which integrates many patches, including security fixes. Some distros and other projects, notably Fedora and FreeBSD, have already switched to our version. It is fully compatible with libmad 0.15.1b.

Note: the MSVC ARM patch was dropped in this version as I don't believe it's needed anymore. If the patch is still needed, we should proceed with applying it to our fork instead.

(Disclaimer: I'm a Tenacity maintainer and also maintain our fork of libmad too)

• Changes comply with the maintainer guide
• SHA512s are updated for each updated download
• The "supports" clause reflects platforms that may be fixed by this new version
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[generic-pers0n]

@generic-pers0n please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree

[JonLiu1993]

@generic-pers0n, thanks for your PR, this is error log, please take a look:

FAILED: mad_example 
: && /android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --target=armv7-none-linux-androideabi21 --sysroot=/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security  -fPIC   -fno-limit-debug-info -static-libstdc++ -Wl,--build-id=sha1 -Wl,--no-rosegment -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments CMakeFiles/mad_example.dir/minimad.c.o -o mad_example  libmad.a  -latomic -lm && :
ld: error: libmad.a(layer3.c.o):(function III_decode: .text.III_decode+0x360): branch and link relocation: R_ARM_THM_CALL to non STT_FUNC symbol: III_imdct_l interworking not performed; consider using directive '.type III_imdct_l, %function' to give symbol type STT_FUNC if interworking between ARM and Thumb is required; layer3.c:2525 (/mnt/vcpkg-ci/b/libmad/src/0-e1f1acd0ee.clean/layer3.c:2525)
ld: error: libmad.a(layer3.c.o):(function III_decode: .text.III_decode+0x49e): branch and link relocation: R_ARM_THM_CALL to non STT_FUNC symbol: III_imdct_l interworking not performed; consider using directive '.type III_imdct_l, %function' to give symbol type STT_FUNC if interworking between ARM and Thumb is required; layer3.c:2550 (/mnt/vcpkg-ci/b/libmad/src/0-e1f1acd0ee.clean/layer3.c:2550)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

[JonLiu1993]

@generic-pers0n, thanks for the PR, when I installed libmad:x64-windows it looked like it was being used incorrectly:

Elapsed time to handle libmad:x64-windows: 11 s
libmad:x64-windows package ABI:
Total install time: 11 s
libmad provides pkg-config modules:

    # MPEG audio decoder library
    mad

[generic-pers0n]

@generic-pers0n, thanks for the PR, when I installed libmad:x64-windows it looked like it was being used incorrectly:

Elapsed time to handle libmad:x64-windows: 11 s
libmad:x64-windows package ABI:
Total install time: 11 s
libmad provides pkg-config modules:

    # MPEG audio decoder library
    mad

This looks correct. I tested an example on Linux and using the mad target works.

This might change upstream later, and if that changes, the usage text will be updated here as needed. For now, this is the correct usage.

[dg0yt]

On Linux, I get CMake usage, and this is what we prefer:

libmad provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(mad CONFIG REQUIRED)
  target_link_libraries(main PRIVATE mad::mad)

This should also be printed on windows, given the CI file lists.

libmad:x64-windows:/share/mad/madConfig.cmake
libmad:x64-windows:/share/mad/madConfigVersion.cmake
libmad:x64-windows:/share/mad/madTargets-debug.cmake
libmad:x64-windows:/share/mad/madTargets-release.cmake
libmad:x64-windows:/share/mad/madTargets.cmake

[JonLiu1993]

Displaying it on Windows is more user-friendly, thanks.

libmad provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(mad CONFIG REQUIRED)
  target_link_libraries(main PRIVATE mad::mad)

[dg0yt]

(Disclaimer: I'm a Tenacity maintainer and also maintain our fork of libmad too)

@generic-pers0n Does your git server offer bitwise stable tarballs for tags? If not, vcpkg_download_distfile can't be used. #36362

[generic-pers0n]

(Disclaimer: I'm a Tenacity maintainer and also maintain our fork of libmad too)

@generic-pers0n Does your git server offer bitwise stable tarballs for tags? If not, vcpkg_download_distfile can't be used. #36362

I was under the impression they were bitwise stable, but potentially not. However, Codeberg recently dealt with a massive DDoS attack, so maybe that had something to do with causing the hash to change or so but I'm not entirely sure.

If needed, we can provide source tarballs ourselves, and I can make one very quickly for libmad's latest release.

[dg0yt]

A manual source tarball might be the easiest solution.
Stable SHA512 are necessary for source asset caching. (And in that way, also for offline builds.) vcpkg CI won't notice changes as long as it has a cached artifact, so the bad experience always hits new users.
(One year ago there was quite some rumour when Github tarballs had changes, and they had to roll back some changes.)

[generic-pers0n]

A manual source tarball might be the easiest solution. Stable SHA512 are necessary for source asset caching. (And in that way, also for offline builds.) vcpkg CI won't notice changes as long as it has a cached artifact, so the bad experience always hits new users. (One year ago there was quite some rumour when Github tarballs had changes, and they had to roll back some changes.)

I will start uploading manual source tarballs with SHA512 hashes soon.

[generic-pers0n]

I have uploaded a tarball of the libmad source. Filenames will follow this structure: libmad-${PORT_VERSION}.tar.gz

The expected SHA512 hash should now be 5b0a826408395e8b6b8a33953401355d6c2f1b33ec5085530b4ac8a538c39ffa903ce2e6845e9dcad73936933078959960b2f3fbba11ae091fda5bc5ee310df5 for 0.16.4.

[ryandesign]

I was under the impression they were bitwise stable, but potentially not.

https://codeberg.org/Codeberg/Community/issues/1366

(One year ago there was quite some rumour when Github tarballs had changes, and they had to roll back some changes.)

Yup, that was the same problem. Both caused by updating to git 2.38 and either not noticing that it changed the archive compression method or not understanding the impact that change would have on users.

A manual source tarball might be the easiest solution.

Yes, all projects everywhere should offer this, for reasons such as this.