Bug 266241
| Summary: | devel/libdatrie build fails if converters/libiconv is installed | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Stefan Eßer <se> |
| Component: | Individual Port(s) | Assignee: | Muhammad Moinur Rahman <bofh> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | evgenyx7c8, freebsd, inbox, jakub_lach, jcfyecrayz, jjb-b, pkubaj, rachid |
| Priority: | --- | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
I am experiencing the same behavior. Thanks to Stefan's post, I got around the problem for now by doing a temporary (forced) delete of libiconv, building libdatrie and then building libiconv. (In reply to Christopher from comment #1) Same here, FreeBSD 13.2-STABLE #0 stable/13-5e7bbde17 amd64 I have the same issue *** Bug 270384 has been marked as a duplicate of this bug. *** A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=5dc1c7edbe955020808f3eca113d1a5f053b67f7 commit 5dc1c7edbe955020808f3eca113d1a5f053b67f7 Author: Muhammad Moinur Rahman <bofh@FreeBSD.org> AuthorDate: 2023-03-21 14:50:03 +0000 Commit: Muhammad Moinur Rahman <bofh@FreeBSD.org> CommitDate: 2023-03-21 14:52:55 +0000 devel/libdatrie: Fix BUILD While converters/libiconv is installed libdatrie fails to build as it tries to use the iconv library from libc which do not contain all the funcntionalities of libiconv. So rather than depending on the base of iconv switch to the port version entirely. PR: 266241 Reported by: se devel/libdatrie/Makefile | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) libdatrie works fine with nl_langinfo (instead of locale_charset) which libc in base has. A small patch to 'configure' detects that case and unpatched tools/trietool.c already supports it. I developed a local patch that allows that back in November, but I did not get around to submitting a patch here at the time, and then I forgot about it until now. Sorry for that. I'll send an alternate patch that does not require the libiconv port for consideration here and upstream. Hmmm... Okay, I did provide a patch upstream: https://github.com/tlwg/libdatrie/issues/25 But I did not ask for a pull request at the time. I'll do that. It'd be nice not to have to depend on libiconv since libdatrie (specifically trietool) already supports it - it's just configure that needs a little nudge to detect the supported usage correctly. Okiz. Send me a git diff patch. I will look into it. (In reply to Muhammad Moinur Rahman from comment #7) Will do. I also issued the upstream pull request. I don't expect much movement on that as the last upstream commit was two years ago. We'll see. (In reply to John Hein from comment #8) link to pull request, FYI... https://github.com/tlwg/libdatrie/pull/27 |
If converters/libiconv is installed, the devel/libdatrie runs a configure test with -liconv, but ${ICONV_LIB} is expanded to an empty string on systems that have iconv functionality in libc.so. But the iconv functionality in libc.so is incomplete, it does specifically lack the locale_charset() function that is provided by libiconv.so (that had been used by the configure script). libtool: link: cc -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -fstack-protector-strong -o .libs/trietool trietool.o -L/usr/local/lib ../datrie/.libs/libdatrie.so -Wl,-rpath -Wl,/usr/local/lib ld: error: undefined symbol: locale_charset >>> referenced by trietool.c >>> trietool.o:(main) cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 To reproduce install converters/libiconv on the base system and then try to build the devel/libdatrie port on the base system. The magic in Uses/iconv.mk does not cover the case where locale_charset() is required by a port. A solution could be to forcefully depend on converters/libiconv and to link against -liconv (instead of ${ICONV_LIB}). Another possibility is to link against libunistring.so in addition to libc.so (but that does only move the extra dependency to a different port). Patching the port to not require locale_charset() but to use nl_langinfo() instead could also allow the port to build in all cases.