gnuplot-beta

Volunteer to add AC_CHECK_LIB() for iconv routines?

[Ethan M. <merritt@u.washington.edu>]

Copyied from the newsgroup, in the hope that someone will
volunteer to add the appropriate checks to ./configure.in

I note with sympathy that the same article cited below says

 "Although they have many problems, and are hated by most of
  their users, Autotools are currently the best way to handle
  a multi-platform, adaptable building system."

Ethan Merritt <merritt@u.washington.edu> wrote:
>lutz <lu...@nu...> wrote:
>>
>>/usr/local/lib/libgd.so: undefined reference to `libiconv_open'
>>/usr/local/lib/libgd.so: undefined reference to `libiconv_close'
>>/usr/local/lib/libgd.so: undefined reference to `libiconv'
>
>On my machine these functions do not come
>from a separate libiconv* library; they are part of the locale
>support provided directly by glibc.

It turns out that this is a "well-known" difference between linux and
BSD-derived systems, something I learned only now via a NewsForge
article on portable configurations:
    http://programming.newsforge.com/article.pl?sid=05/07/19/1713230

It suggests adding an AC_CHECK_LIB() macro to the configuration script 
that checks for the iconv routines.  Maybe we should do that.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Volunteer to add AC_CHECK_LIB() for iconv routines?

[Lars H. <lhe...@us...>]

Ethan Merritt writes:
> Copyied from the newsgroup, in the hope that someone will
> volunteer to add the appropriate checks to ./configure.in
 
 Try this fragment. I added it to GD's configure for 2.0.9.

AM_ICONV
if test -n "$LIBICONV" ; then
  LIBS="$LIBS $LIBICONV"
fi
 
AC_CHECK_HEADERS(iconv.h,
  [AC_MSG_CHECKING(whether iconv.h defines iconv_t)
   AC_EGREP_HEADER([typedef.*iconv_t],iconv.h,
     [AC_MSG_RESULT(yes)
      AC_DEFINE(HAVE_ICONV_T_DEF, 1,
                [Define if <iconv.h> defines iconv_t.])],
      AC_MSG_RESULT(no))])

Re: Volunteer to add AC_CHECK_LIB() for iconv routines?

[<br...@ph...>]

Ethan Merritt wrote:
> It suggests adding an AC_CHECK_LIB() macro to the configuration script 
> that checks for the iconv routines.  Maybe we should do that.

I don't think so.  The actual problem here is that a gnuplot build was 
failing on functions in -liconv, which gnuplot doesn't use at all.  I 
can see no sane reason we should have to check for a library which we 
never use.

The dependence on this library was introduced by -lgd, in that case, and 
as far as I can tell, the actual reason the build failed was that our 
configure script checks for the existence of gdlib-config (which exists 
for the exact purpose of informing us about such dependencies of -lgd on 
other libraries) but still insists on trying its own tests even if 
gdlib-config was found.  That feels quite wrong to me.  I think that if 
we did find gdlib-config, all direct tests for libgd features have to be 
done against output of that tool.

The second half of the original problem may well have been that the OP's 
gdlib-config was buggy.

Re: Volunteer to add AC_CHECK_LIB() for iconv routines?

[Hans-Bernhard B. <br...@ph...>]

Hans-Bernhard Br=F6ker wrote:

[GD detection failures caused by undefined references into -liconv...]

> other libraries) but still insists on trying its own tests even if=20
> gdlib-config was found. =20

The original reporter of this problem has since provided more=20
information.  Turns out the key mistake was that not only shouldn't our=20
configure be trying to test libgd features by running test links; it's=20
getting those testlinks critically wrong, too.  They don't use the=20
necessary libraries as reported by "gdlib-config --libs".  Moving this=20
fragment in configure.in:

   if test -n "$GDLIB_CONFIG"; then
     libgd_LIBS=3D`gdlib-config --libs`
   fi

to a point *before* we try AC_CHECK_LIB() calls on libgd features, might =

already help.  But the correct approach would be not to test links at=20
all, if gdlib-config is available: it already reports everything we want =

to know about libgd, including the feature selection.

So, to summarize: there is an error our configure.in that's causing=20
those problems, and there's no point in explicitly checking for -liconv=20
as a workaround.