[GRASS-dev] Is grass70b4 compiling on FreeBSD ?
fabio.dias at gmail.com
Tue Jan 6 12:00:26 PST 2015
# locate iconv.h
The files /usr/include/iconv.h and /usr/local/include/iconv.h are different.
I removed the local one, re-run ./configure (both iconv related
messages: yes) and gmake. Same deal. No -liconv included on
include/Make/Platform.make, same error when linking.
I also removed the --with-includedir=local and added iconv.h from another dir:
/configure --with-includes=~/ --with-postgres --with-pthread
--with-geos --with-wxwidgets --with-lapack --with-sqlite
Same deal. It says yes for both iconv tests and doesn't link it.
It is important to say that I didn't fiddle around much, I think. The
box is pretty much a fresh free 10.1 install...
Fábio Augusto Salve Dias
On Wed, Dec 31, 2014 at 8:01 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
> Fábio Dias wrote:
>> The "important" part, afaik, is :
>> undefined reference to `libiconv'
>> undefined reference to `libiconv_close'
>> 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
> 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.])
> 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>
More information about the grass-dev