[GRASS-dev] Adding path iconv library to ./configure

[Markus Metz]

On Wed, Feb 26, 2020 at 5:35 PM Vaclav Petras <wenzeslaus at gmail.com> wrote:
>
> Dear all,
>
> In order to compile in a conda environment (where iconv is installed
through conda, not in the system), I'm trying to add a path to icon into
./configure(.in). The issue is that although GRASS happens to configure
properly, the compilation fails because libiconv.* is not found.

it seems that GRASS configure uses iconv from libc if present, but at
compile time this is not always true: sometimes iconv from libiconv is
attempted to be used and not from libc.

See https://lists.osgeo.org/pipermail/grass-dev/2014-December/072690.html

Most importantly, regarding only iconv:

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

This needs to be fixed.If the configure checks pass, the settings used by
configure (included headers, linkied libraries) need to be used as compile
time.

Markus M

>
> I have added code which is used for other libraries, although I'm not
sure what exactly should I do for a mandatory dependency. The part which
seems to be failing is AC_CHECK_FUNC.
>
> ac_save_ldflags="$LDFLAGS"
> LDFLAGS="$LDFLAGS $ICONVLIBPATH"
> # LDFLAGS now contains the path set using --with-iconv-libs
> 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)
> LDFLAGS="${ac_save_ldflags}"
> # The AC_CHECK_FUNC step above seems to succeed
> # The output is "checking for iconv... yes"
> # The step below fails because $ICONVLIB is empty
> # With "checking for iconv in -l... no"
> LOC_CHECK_LIBS($ICONVLIB,iconv,iconv,$ICONVLIBPATH,ICONV,,,)
>
> I'm including a full diff too. Note that the iconv library is different
from the others because our ./configure allows for different names of the
library.
>
> Alternative would be to use LDFLAGS. That would be actually ideal,
because all libraries are just at one common prefix. However, providing it
as a parameter to ./configure (which seems to be the recommended way even
over the above) results in "unknown platform" and providing it as an
environmental variable does not have any effect.
>
> Please, let me know if you have any advice,
> Vaclav
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20200226/07ace58e/attachment.html>