[tlbuild] missing libiconv when compiling xdvik on FreeBSD

[Johannes Hielscher]

Hi,

just to make things more complicated: my build on FreeBSD 11.1 does
still work well, produces a working xdvi binary, and passes all tests.

I exported TL_COMPILER_GFLAGS="-I/usr/local/include" (so that --with-x
--enable-xetex finds all its third-party dependencies in
/usr/local/{include,lib}). But in my environment, the linker was not
confused by the two iconv.h present from BSD and the GNU iconv from the
converters/libiconv port (which is, BTW, not listed by Nikola as a
prerequisite at http://anthesphoria.net/FreeBSD/TeXLive-2017/ ).

In fact, the GNU folks added a paragraph of warning about this at the
top of /usr/local/include/iconv.h:

  /* We would like to #include any system header file which could define
     iconv_t, 1. in order to eliminate the risk that the user gets
  compilation errors because some other system header file
  includes /usr/include/iconv.h which defines iconv_t or declares iconv
  after this file, 2. when compiling for LIBICONV_PLUG, we need the
  proper iconv_t type in order to produce binary compatible code.
     But gcc's #include_next is not portable. Thus, once libiconv's
  iconv.h has been installed in /usr/local/include, there is no way any
  more to include the original /usr/include/iconv.h. We simply have to
  get away without it.
     Ad 1. The risk that a system header file does
     #include "iconv.h"  or  #include_next "iconv.h"
     is small. They all do #include <iconv.h>.
     Ad 2. The iconv_t type is a pointer type in all cases I have seen.
  (It has to be a scalar type because (iconv_t)(-1) is a possible
  return value from iconv_open().) */


I'd be happy to test resolutions that work for Mojca, too.

Best,
Johannes