Here's a build fix for databases/gq on aarch64, but it's ugly, and there's a more general problem.
GNU libiconv doesn't actually provide iconv() etc., but libiconv() and maps the functions with <iconv.h> to the standard names. This causes naive link checks to fail. The recommended upstream iconv.m4 autoconf check that handles all this is rather large, pulls in more macros, and may be difficult to retrofit into old configure.in scripts written for obsolete autotools versions. Instead, it is simpler to just override the check and assert that we indeed have iconv(). The failing test causes the final link command line to omit -liconv. The iconv() function is still referenced from the code (that's a bug), and since libiconv.so is pulled in as a dependency of some other library, linking succeeds with our old binutils. It does, however, fail with lld (and would with new binutils). So the port is broken on aarch64 and overriding the test fixes it there. I'm explaining this because the same problem may affect additional ports, so we might want to decide carefully if we want this hack. The alternative is to take iconv.m4, or maybe a version of iconv.m4 contemporary with the release of the affected port, and re-run the autotools cascade, which might trigger its own share of problems. Opinions? Index: Makefile =================================================================== RCS file: /cvs/ports/databases/gq/Makefile,v retrieving revision 1.58 diff -u -p -r1.58 Makefile --- Makefile 21 Nov 2017 00:12:59 -0000 1.58 +++ Makefile 27 Apr 2018 14:28:20 -0000 @@ -35,4 +35,9 @@ USE_GMAKE= Yes CONFIGURE_STYLE=gnu CONFIGURE_ARGS= --enable-browser-dnd +# GNU libiconv provides libiconv_open() which is mapped to iconv_open() +# by <iconv.h>, so a simple link check fails. Rather than regenerating +# configure with iconv.m4, just override the test. +CONFIGURE_ENV+= ac_cv_lib_iconv_iconv_open=yes + .include <bsd.port.mk> -- Christian "naddy" Weisgerber [email protected]
