# 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 <[email protected]> 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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
