configure fails to detect GD due to wrong libiconv being used

[dmorissette]

Håvard Tveite wrote:
> I downloaded the nightly build an hour ago. configure
> has problems finding a working gd version (configure
> for 4.2.5 has no problems).
> I am on Solaris 2.7, gcc 3.3.2, gnu make 3.80, gd 2.0.28, ...
> 
> I use the following configure command:
> ./configure --prefix=/usr/local --with-httpd=/usr/local/apache2/bin/httpd
> --with-sde=/users/ikf/sde/sdeexe80 --with-proj=/usr/local --with-wmsclient
> --with-wfs --with-wfsclient --with-wcs --with-ogr=/usr/local/bin/gdal-config
> --with-gd=/usr/local --with-zlib=/usr/local
> --with-gdal=/usr/local/bin/gdal-config --without-tiff --without-jpeg
> --with-postgis=/usr/local/pgsql/741/bin/pg_config --with-pdf=/usr/local
> --enable-debug
> 
> This is where configure stops for the nightly build:
> **********************
> checking for iconv_open in -lc... yes
>         using libiconv from system libs.
>         libiconv found. Enabling internationalization (-DUSE_ICONV)
> configure: checking for GD 2.0.12 or higher......
> checking for gdImageSetAntiAliased in -lgd... no
> configure: checking whether GD needs libiconv......
> checking for gdImageSetAntiAliased in -lgd... no
> configure: error: "Could not find gd.h or libgd.a/libgd.so in /usr/local.
> Make sure GD 2.0.12 or higher is compiled before calling configure."
> **********************
> (the header file and libraries *are* in /usr/local/include and /usr/local/lib)
> 
> The same configure command works for 4.2.5:
> **********************
> checking for libiconv_open in -liconv... yes
>         using libiconv from system libs.
> configure: checking for GD 2.0.12 or higher......
> checking for gdImageSetAntiAliased in -lgd... no
> 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
> checking for gdImageGif in -lc... yes
> checking for gdImagePng in -lc... yes
> checking for gdImageJpeg in -lc... yes
> checking for gdImageWBMP in -lc... yes
> checking for gdImageStringFT in -lc... yes
> checking for gdImageGifPtr in -lc... yes
>         using GD ( -DUSE_GD_GIF -DUSE_GD_PNG -DUSE_GD_JPEG -DUSE_GD_WBMP
> -DUSE_GD_FT -DGD_HAS_GDIMAGEGIFPTR) from /usr/local.
> **********************
>

[dmorissette]

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

[dmorissette]

I have been able to reproduce this. 

This happens if you use --with-libiconv-prefix to compile GD with a local
libiconv. Everything works fine if you do not include this GD configure option.

[havard.tveite@…]

I configured GD with as follows (I did not specify --with-libiconv-prefix)

./configure --with-png=/usr/local --with-freetype=/usr/local
--with-jpeg=/usr/local --with-xpm=/usr/local

[dmorissette]

Fixed (will be in 4.4.0-beta2)

Depending on your system configuration, the new configure script may
automatically find your local libiconv. If not then you will have to specify the
location of your libiconv using --with-libiconv=<prefix>. This was not clear so
I clarified the error message to say the following:

"Could not find gd.h or libgd.a/libgd.so in $GD_DIR.  Make sure GD 2.0.12 or
higher is compiled before calling configure. You may also get this error if you
didn't specify the appropriate location for one of GD's dependencies (freetype,
libpng, libjpeg or libiconv)."

Note however that due to bug 909, this would have produced a linking error later
on. With bug 909 fixed you should be able to complete your build.

[havard.tveite@…]

I have tried the new nightly build (hoping that Daniels changes
had made it to the nightly build).

I configured GD as follows (GNU Autoconf 2.57):
./configure --with-png=/usr/local --with-freetype=/usr/local
--with-jpeg=/usr/local --with-xpm=/usr/local --without-libiconv-prefix

If I removed --without-libiconv-prefix (or used
--with-libiconv-prefix=/usr/local), Mapserver configuration
aborted with the same error message as before.

I was then able to configure mapserver with the following:

./configure --prefix=/usr/local --with-httpd=/usr/local/apache2/bin/httpd
--with-sde=/users/ikf/sde/sdeexe80 --with-proj=/usr/local --with-wmsclient
--with-wfs --with-wfsclient --with-wcs --with-ogr=/usr/local/bin/gdal-config
--with-gd=/usr/local --with-zlib=/usr/local
--with-gdal=/usr/local/bin/gdal-config --without-tiff --without-jpeg
--with-postgis=/usr/local/pgsql/741/bin/pg_config --with-pdf=/usr/local
--enable-debug
(-> "using libiconv from system libs")

Compilation went OK, but linking failed:
gcc -g -O2 -fPIC -Wall -DENABLE_STDERR_DEBUG -DNEED_NONBLOCKING_STDERR
-DIGNORE_MISSING_DATA -DNEED_STRLCAT  -DUSE_EPPL -DUSE_PROJ -DUSE_PROJ_API_H
-DUSE_WMS_SVR -DUSE_WMS_LYR -DUSE_WFS_SVR -DUSE_WFS_LYR -DUSE_WCS_SVR    
-DUSE_GD_GIF -DUSE_GD_PNG -DUSE_GD_JPEG -DUSE_GD_WBMP -DUSE_GD_FT
-DGD_HAS_GDIMAGEGIFPTR -DGD_HAS_GETBITMAPFONTS -DUSE_PDF -DUSE_SDE -DUSE_OGR
-DUSE_GDAL  -DUSE_ICONV  -DUSE_POSTGIS    -I/usr/local/include
-I/usr/local/include -I/usr/local/include    -I/users/ikf/sde/sdeexe80/include 
 -I/usr/local/include -I/usr/local/pgsql/741/include  -I/usr/local/include     
shp2img.o  -L. -lmap -L/usr/local/lib -lgd -ljpeg -lfreetype -lpng
-L/usr/local/lib -lz -lXpm -lX11  -L/usr/local/lib64 -lpdf -ljpeg -lfreetype
-lpng -L/usr/local/lib -lz -lXpm -lX11  -L/usr/local/lib -lproj -ljpeg
-L/users/ikf/sde/sdeexe80/lib -lsde80 -lpe80 -lsg80 -lpthread -lsocket -ldl
-L/usr/local/lib -lgdal  -L/usr/local/pgsql/741/lib -lpq  -L/usr/local/lib
-lcurl -L/usr/local/lib -R/usr/local/lib -R/usr/lib -L/usr/lib
-R/usr/openwin/lib -L/usr/openwin/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib
-L/usr/local/ssl/lib -lz -lssl -lcrypto -ldl -lsocket -lnsl     -lc  -lm
-lstdc++  -o shp2img
Undefined                       first referenced
 symbol                             in file
libiconv_close                      ./libmap.a(mapgd.o)  (symbol belongs to
implicit dependency /usr/local/lib/libiconv.so.2)
libiconv                            ./libmap.a(mapgd.o)  (symbol belongs to
implicit dependency /usr/local/lib/libiconv.so.2)
libiconv_open                       ./libmap.a(mapgd.o)  (symbol belongs to
implicit dependency /usr/local/lib/libiconv.so.2)
ld: fatal: Symbol referencing errors. No output written to shp2img
collect2: ld returned 1 exit status
make: *** [shp2img] Error 1


The only way I was able to compile a working version of Mapserver was to
remove libiconv.* from /usr/local/lib and iconv.h from /usr/local/include.
I would rather not, though.

[dmorissette]

Since your GD is built with a local libiconv, you need to specify where to find
that libiconv to MapServer (just the fact that you have iconv.h in
/usr/local/include together ith other header files used in your build may
require that too). 

This is done using the --with-libiconv=<prefix> where <prefix> is the prefix
where libiconv is installed, likely /usr/local (note that it is *not*
--with-libiconv-prefix=... contrary to GD)

So I'd suggest that you try the following:

./configure --with-png=/usr/local --with-freetype=/usr/local
--with-jpeg=/usr/local --with-xpm=/usr/local --with-libiconv=/usr/local

[havard.tveite@…]

First I put the libiconv files back in /usr/local/lib and
/usr/local/include (where they were before I started this
experimentation).
Then I recompiled GD with:
./configure --with-png=/usr/local --with-freetype=/usr/local
--with-jpeg=/usr/local --with-xpm=/usr/local --with-libiconv-prefix=/usr/local

Then I modified my Mapserver configuration according to Daniels suggestion:
./configure --with-png=/usr/local --with-freetype=/usr/local
--with-jpeg=/usr/local --with-xpm=/usr/local --with-libiconv=/usr/local

The following output resulted (only the tail is shown):
...
configure: checking where libiconv is installed......
checking for iconv_open in -liconv... yes
checking for iconv_open in -lc... yes
        using libiconv from -L/usr/local/lib -lc
        libiconv found. Enabling internationalization (-DUSE_ICONV)
configure: checking for GD 2.0.12 or higher......
checking for gdImageSetAntiAliased in -lgd... no
configure: checking whether GD needs libiconv......
checking for gdImageSetAntiAliased in -lgd... no
checking for gdImageSetAntiAliased in -lgd... (cached) no
configure: checking whether GD needs libiconv......
checking for gdImageSetAntiAliased in -lgd... no
configure: error: "Could not find gd.h or libgd.a/libgd.so in /usr/local.  Make
sure GD 2.0.12 or higher is compiled before calling configure."


An attempt to explain what is happening:
Configure finds the iconv functions in both libiconv (presumably
in /usr/local/lib) and libc (presumably in /usr/lib).
It determines to use the libc variant ("-lc") and not the
libiconv variant ("-liconv"), but tries to find a libc with
iconv in /usr/local/lib ("-L/usr/local").

[dmorissette]

You still get the old error message:

configure: error: "Could not find gd.h or libgd.a/libgd.so in /usr/local.  Make
sure GD 2.0.12 or higher is compiled before calling configure."


Looks like you're still using the old configure script. Perhaps try getting
source from CVS instead of downloading the nightly build.

[havard.tveite@…]

The CVS version was OK.