With lld 17, which has become more strict about undefined symbols in version scripts, security/rhash fails to link its librhash.so: ld: error: version script assignment of 'global' to symbol 'rhash_wfile' failed: symbol not defined This has been fixed in https://github.com/rhash/RHash/commit/e4b8b92, which was included in rhash 1.4.4, so update the port to that version. Unfortunately this also requires a bunch of follow-up build fixes: * https://github.com/rhash/RHash/commit/c804982: fix assignment * https://github.com/rhash/RHash/commit/9ef90b9: build on *BSD * https://github.com/rhash/RHash/commit/b8c91ea: build on Unix
Created attachment 244829 [details] security/rhash: update to 1.4.4 and fix build with lld 17
> This has been fixed in https://github.com/rhash/RHash/commit/e4b8b92, > which was included in rhash 1.4.4, so update the port to that version. I'm thinking whether backporting this particular patch against existing version 1.4.3 would be sufficient (and a better way). I've tried to update the port to version 1.4.4 a while ago and it didn't build cleanly as before. > Unfortunately this also requires a bunch of follow-up build fixes Probably related, yes. Before your PR, I planned to skip 1.4.4 because I didn't want to pull several patches given that 1.4.3 builds cleanly and works fine.
(In reply to Alexey Dokuchaev from comment #2) Yes, backporting just the patch for the version script was the first thing I did, and it also works of course. The changelog from 1.4.3 to 1.4.4 looks like this: * Remove obsolete rhash_timer functions (API breaking change) * Increment LibRHash soname version on Linux and Unix * Support leading and trailing spaces in a file names * Changed the simple file format to fit the sfv format * Bugfix: Fix slash usage with wilcards on Windows * Print the algorithms being calculated on -vv * Renamed --maxdepth option to --max-depth * Supported escaping of special characters in file paths * New printf-format directive '%d' to print file directory * New option --unverified to print unverified files * New option --missing to print missing files so is that "interesting" enough for putting in a new release? If it's mostly breaking API and renaming command line options, and not a lot of optimizations and/or bug fixes, it's probably not worth it. Let me know what your preference is.
Created attachment 244835 [details] security/rhash: fix build with lld 17 Alternative fix, just applying the one patch.
Created attachment 244837 [details] security/rhash: fix build with lld 17 Oops, fix tab for PORTREVISION.
(In reply to Dimitry Andric from comment #5) Shall I commit the version with just the one patch, and not bump the upstream version?
Comment on attachment 244829 [details] security/rhash: update to 1.4.4 and fix build with lld 17 > so is that "interesting" enough for putting in a new release? Yeah, you've convinced me, let's go with the update, esp. given that the difference is basically the number of patches, i.e. minuscule. > Shall I commit the version with just the one patch? No, please go ahead with the update to 1.4.4, just make sure it does not break consumers (most importantly, `devel/cmake-core'), thank you!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e0acbd158ec92f50ecbf8932a57b9d7587564138 commit e0acbd158ec92f50ecbf8932a57b9d7587564138 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2023-09-14 08:45:45 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2023-09-20 20:12:31 +0000 security/rhash: update to 1.4.4 and fix build with lld 17 With lld 17, which has become more strict about undefined symbols in version scripts, security/rhash fails to link its librhash.so: ld: error: version script assignment of 'global' to symbol 'rhash_wfile' failed: symbol not defined This has been fixed in https://github.com/rhash/RHash/commit/e4b8b92, which was included in rhash 1.4.4, so update the port to that version. Unfortunately this also requires a bunch of follow-up build fixes: * https://github.com/rhash/RHash/commit/c804982: fix assignment * https://github.com/rhash/RHash/commit/9ef90b9: build on *BSD * https://github.com/rhash/RHash/commit/b8c91ea: build on Unix PR: 273775 Approved by: danfe (maintainer) MFH: 2023Q3 security/rhash/Makefile | 7 ++++++- security/rhash/distinfo | 12 +++++++++--- security/rhash/pkg-plist | 3 ++- 3 files changed, 17 insertions(+), 5 deletions(-)
I had to tweak pkg-plist too, to adjust for the new two-level soname symlinks (e.g. librhash.so.1.4.4, librhash.so.1 and librhash.so). I verified that cmake-core builds successfully. Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=28149de0a616dd364bce3485aafb31dcfba27946 commit 28149de0a616dd364bce3485aafb31dcfba27946 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2023-09-21 07:31:51 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2023-09-21 07:38:37 +0000 devel/cmake-core devel/cmake-gui misc/mbuffer: cope with librhash.so bump Because rhash 1.4.4 updated the librhash.so symlink from .0 to .1, build-time dependents such as cmake-core and cmake-gui need their PORTREVISION bumped. The other case is misc/mbuffer, which uses librhash only at runtime, but hardcodes dlopen("librhash.so.0", RTLD_NOW). I changed this to just "librhash.so", and it seems to work fine with light testing. PR: 273775 Reported by: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Fixes: e0acbd158ec9 security/rhash: update to 1.4.4 and fix build with lld 17 MFH: 2023Q3 devel/cmake-core/Makefile | 2 +- devel/cmake-gui/Makefile | 1 + misc/mbuffer/Makefile | 1 + misc/mbuffer/files/patch-hashing.c (new) | 11 +++++++++++ 4 files changed, 14 insertions(+), 1 deletion(-)
(In reply to commit-hook from comment #10) Confirmed. Thanks! And sorry for missing hardcoded shlib name in misc/mbuffer. I've installed devel/cmake-core only within 3 bumped ports.