configure problems - nightly build

[Daniel Morissette]

That's an interesting one. It seems that the problem may be related to
duplicate copies of the iconv functions on your system (in libiconv.so
and libc.so).

The nightly build finds the iconv functions in libc (-lc):

Håvard Tveite wrote:
>
> checking for iconv_open in -lc... yes
>         using libiconv from system libs.

but fails all the other tests, suggesting that this GD was built using
another libiconv and would need (-liconv) in the link line to pass the
tests:

> configure: checking for GD 2.0.12 or higher......
> checking for gdImageSetAntiAliased in -lgd... no


... this is confirmed by the 4.2.5 output:

A libiconv.so is found on the system (-liconv):

>
> The same configure command works for 4.2.5:
> **********************
> checking for libiconv_open in -liconv... yes
>         using libiconv from system libs.


... and GD passes the tests when -liconv is included in the link line:

> configure: checking whether GD needs libiconv......
> checking for gdImageSetAntiAliased in -lgd... yes
>         using libgd 2.0.12 (or higher) from -L/usr/local/lib -lgd -ljpeg
> -lfreetype -lpng -L/usr/local/lib -lz -lXpm -lX11 -liconv

I have filed bug 1017 about this issue. I'll see if I can fix the
configure script to better handle this situation:
http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1017

In the meantime you could try to rebuild your GD using the iconv
functions from libc.so... I would hope that this is what the GD build
scripts would do by default if you do not have a local copy if libiconv
on your system but I may be wrong. I never tried that. If you could copy
your GD configure command to the bug that may help.

Daniel
--
------------------------------------------------------------
  Daniel Morissette               dmorissette at dmsolutions.ca
  DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------