rockdaboot
"--with-libiconv-prefix" seems to be a NOP
The configure option --with-libiconv-prefix seems to be a NOP or not working properly as advertised. Using it makes the configure run through fine, but during the build stage linking errors appear (grabbing an outdated system iconv from Mac OS X here in my case).
./configure --prefix=/usr/local/targetdirectory/libpsl/0.21.2 --with-libiconv-prefix=/usr/local/targetdirectory/libiconv/latest …
Only "-liconv" makes it to the generated Makefile, but no "-I/usr/local/targetdirectory/libiconv/latest/include" or "-L/usr/local/targetdirectory/libiconv/latest/lib"
I have to use the CPPFLAGS/LDFLAGS/LIBS variables kludge as workaround to make things work as wanted:
./configure --prefix=/usr/local/targetdirectory/libpsl/0.21.2 \
--with-libiconv-prefix=/usr/local/targetdirectory/libiconv/latest \
CPPFLAGS="-I/usr/local/targetdirectory/libiconv/latest/include" \
LDFLAGS="-L/usr/local/targetdirectory/libiconv/latest/lib" \
LIBS="-liconv" \
…
Libpsl doesn't directly use libiconv. But for static builds we need to check whether libiconv is available (needed by libunistring). This is done by AM_ICONV in configure.ac, which also installs or pulls in the --with-libiconv-prefix option. I am currently not aware of a simple solution. And AFAIR, AM_ICONV was only needed for some (ancient) systems/environments.
It's needed for a relative variety of systems, basically any system that doesn't have iconv available inside of libc itself. For systems that use GNU glibc, it is builtin. Other systems may or may not have one. GNU libiconv is a popular and portable implementation that can be compiled as an external library for systems which don't have a builtin one.
FreeBSD, for example, has a builtin iconv for a while now, but it's a much simpler one so many applications strongly prefer to be built against GNU libiconv.
Independent of this, AM_ICONV is a fantastically complicated pile of hackishness, that along with supporting many systems that are quite ancient also feels the need to re-implement all the detection logic for GNU libiconv itself. Of course this would simply magically work if libiconv provided pkg-config files, but the maintainer of GNU libiconv has formulated a personal opinion (not endorsed by the GNU project) that including a pkg-config file in your project automatically makes your entire project no longer qualify as Free/Libre and Open Source Software[^1]; hence he utterly refuses to condone adding one.
The home-brewed --with-libiconv-prefix logic is somewhat obtuse and looks like it should probably be buggy. But I haven't felt the urge to look at it too closely because I myself don't have to use it... :)
[^1]: Apparently the purpose of free software is not merely that you are technically capable of downloading and modifying the software to suit yourself, but that you are "invited" to do so. Also, apparently, AM_ICONV invites you to do so but pkg-config does not. How this is connected, I have never quite understood.
@TurtleWilly If anything i still unclear, feel free to reopen or open a new issue.