Bug 256583
| Summary: | audio/lame: patch and unbreak on riscv64 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Robert Clausecker <fuz> | ||||
| Component: | Individual Port(s) | Assignee: | Alexander Leidinger <netchild> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | diizzy, pkubaj | ||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(netchild) |
||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Hi Robert, Alexander has stated previously that this port will only follow upstream so I'd suggest that you submit the patch over at https://sourceforge.net/p/lame/patches/ Best regards, Daniel An upstream issue has been submitted. Keeping this one open until the fix has made its way into this port.
https://sourceforge.net/p/lame/patches/96/
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=fd14cb96eb4d160d6d173447546ea025f55b2882 commit fd14cb96eb4d160d6d173447546ea025f55b2882 Author: Alexander Richardson <arichardson@llvm.org> AuthorDate: 2021-06-19 12:39:17 +0000 Commit: Alexander Leidinger <netchild@FreeBSD.org> CommitDate: 2021-06-19 12:43:54 +0000 audio/lame: fix build on riscv The previous commit only removed the BROKEN for riscv, but didn't add a patch. PR: 256583 Reported by: Robert Clausecker <fuz@fuz.su> Obtained from: LLVM project https://reviews.llvm.org/D89557 audio/lame/Makefile | 2 +- audio/lame/files/patch-libmp3lame_util.c (new) | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) Committed. Thanks! |
Created attachment 225775 [details] audio/lame: patch and unbreak on riscv64 Lame is currently BROKEN on riscv64 due to an unsupported fpsetenv() call. RISC-v does not have floating point exceptions and nobody bothered to stub out the function in the libc. This is a patch by the LLVM project to unbreak the build on platforms such as riscv64 with incomplete fpsetmask support. On riscv64 specifically, there are no traps for invalid floating point operations, so whatever this masking code tries to achieve is meaningless anyway.