[GRASS-dev] Is grass70b4 compiling on FreeBSD ?

[Fábio Dias]

# locate iconv.h
/usr/include/iconv.h
/usr/include/sys/iconv.h
/usr/local/include/boost/math/special_functions/detail/iconv.hpp
/usr/local/include/iconv.h
/usr/local/include/libgsf-1/gsf/gsf-output-iconv.h
/usr/local/lib/gcc48/include/c++/gnu/gcj/convert/Input_iconv.h
/usr/local/lib/gcc48/include/c++/gnu/gcj/convert/Output_iconv.h
/usr/ports/lang/gcc/work/gcc-4.8.3/libjava/gnu/gcj/convert/Input_iconv.h
/usr/ports/lang/gcc/work/gcc-4.8.3/libjava/gnu/gcj/convert/Output_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-gdal --with-includes=/usr/local/include
--with-libs=/usr/local/lib
--with-freetype-includes=/usr/local/include/freetype2 --with-readline
--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
http://sites.google.com/site/fabiodias/


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 :
>> /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>