[GRASS-dev] Is grass70b4 compiling on FreeBSD ?

[Glynn Clements]

Fábio Dias wrote:

> The "important" part, afaik, is :
> /usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
> undefined reference to `libiconv'
> /usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
> undefined reference to `libiconv_close'
> /usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
> undefined reference to `libiconv_open'
> 
> So I've tried with --with-iconv on the configure, not that this option
> exist... Then I manually changed a Makefile, on one of the directories
> with error. Added -liconv to he LIBES var, then the make worked. My
> guess would be that configure isn't passing along the -liconv properly
> in this context...

This looks like a mismatch between iconv implementations, i.e. using
the headers from libiconv with a libc which supports iconv natively.

In the configure script, the header checks and the library checks are
disconnected.

One part of the script checks that iconv.h exists (more precisely,
that a source file which contains nothing but "#include <iconv.h>" can
be pre-processed without error).

Another part checks that a function named iconv or libiconv exists,
either when linking with the default libraries (i.e. with no -l
switches) or with -liconv or -lgiconv. To be precise, it checks that a
test program which references the function can be linked without
error. The test program doesn't include any headers; it declares its
own prototype for the function (that's just how autoconf's
AC_CHECK_FUNC and AC_CHECK_LIB macros work).

If you use a "libiconv"-style implementation, the headers define iconv
as a macro which expands to libiconv (likewise for iconv_open and
iconv_close). The library provides functions called libiconv etc.

If the platform's libc provides iconv, the functions are named iconv,
iconv_open, iconv_close (i.e. no "lib" prefix).

What I suspect is happening is that the linkage checks:

	AC_CHECK_FUNC(iconv, ICONVLIB=, [
	AC_CHECK_LIB(iconv, iconv, ICONVLIB=-liconv, [
	AC_CHECK_LIB(giconv, iconv, ICONVLIB=-lgiconv, [
	AC_CHECK_FUNC(libiconv, ICONVLIB=, [
	AC_CHECK_LIB(iconv, libiconv, ICONVLIB=-liconv, [
	AC_CHECK_LIB(giconv, libiconv, ICONVLIB=-lgiconv, [
	    AC_MSG_WARN([*** Unable to locate iconv() function.])
	    ICONVLIB=
	])])])])])])
	AC_SUBST(ICONVLIB)

determine that the iconv function is available by default, with no
additional libraries required (i.e. it's built into libc). I.e. the
first test succeeds, resulting in ICONVLIB being empty.

But the iconv.h header which is found during compilation is for a
libiconv implementation, not for libc's implementation (possibly due
to the use of /usr/local/include). So the resulting program has a
dependency upon the functions from libiconv (which isn't linked)
rather than those in libc (which is linked).

If my suspicion is correct, you should be able to avoid the issue by
creating an additional include directory containing only libc's
iconv.h file (or a symlink to it) and placing that directory before
/usr/local/include in the argument to the --with-includes= switch.

Alternatively, you could temporarily remove or rename the iconv.h in
/usr/local/include while compiling GRASS (I'm not sure why that would
need to be there if the system libc provides iconv).

-- 
Glynn Clements <glynn at gclements.plus.com>