[Uim] Fun with autoconf and friends [patches included]

Jeroen Ruigrok/asmodai asmodai at wxs.nl
Sun Feb 20 18:24:57 EET 2005

On my DragonFly (FreeBSD 4-derived OS) machine I am trying to get uim up and
working.  I am using a snapshot from a few hours ago and running configure I
am getting this funny sequence:

checking for iconv... /usr/local/bin/iconv
checking for msgfmt... /usr/local/bin/msgfmt
checking for msgmerge... /usr/local/bin/msgmerge
checking for xgettext... /usr/local/bin/xgettext
checking for ld used by GCC... /usr/libexec/binutils212/elf/ld
checking if the linker (/usr/libexec/binutils212/elf/ld) is GNU ld... yes
checking for shared library run path origin... ./config.rpath: Can't open ./config.rpath: No such file or directory
checking for iconv... no, consider installing GNU libiconv
configure: error: Could not find iconv (required for uim)

$ which iconv

$ iconv --version
iconv (GNU libiconv 1.9)
Copyright (C) 2000-2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
Written by Bruno Haible.

I call configure with --prefix=/usr/X11R6 though, so it seems that the
configure script tries to do a linking to -liconv, which is located in
/usr/local/lib and is not specified on the command line compilation within

+ eval echo configure:20236: "$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS
$LDFLAGS conftest.$ac_ext $LIBS >&5"
+ echo configure:20236: gcc -o conftest    conftest.c  -liconv >&5
+ ac_status=1

Adding explicit CPPFLAGS=-I/usr/local/include and LDFLAGS=-L/usr/local/lib
prior to the configure invocation solves this, but the message from
configure is quite misleading in this aspect, since the problem is libiconv.
[See attached patch for suggestion.]

Another thing that strikes me as wonderfully odd is the following:

checking for stdbool.h that conforms to C99... no
checking for _Bool... no

And check against the compilation options:

configure:29801: gcc -c  -O2 -Wall -std=gnu89 -pedantic -Wchar-subscripts
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith
-Wcast-align -Wsign-compare -I/usr/local/include conftest.c >&5


configure:29857: gcc -c  -O2 -Wall -std=gnu89 -pedantic -Wchar-subscripts
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith
-Wcast-align -Wsign-compare -I/usr/local/include conftest.c >&5

If you are testing against C99 features, using -std=gnu89 will (probably)
never allow it to work since "[...] You may also select an extended version
of the C language explicitly with `-std=gnu89' (for C89 with GNU extensions)
or `-std=gnu99' (for C99 with GNU extensions)."  Seems to be hardwired in
one of the autotools though.  (Of course stdbool.h is quite a simple include
file, but I hope the point I make above makes sense.)

Also funny is to take the stdbool.h test separate:

using GCC 2.95.4:

gcc bool.c 
bool.c:26: size of array `d' is negative
bool.c:27: warning: initialization makes integer from pointer without a cast

and return value becomes 1.

Using GCC 3.4.3:

gcc bool.c 

and return value is 0.

Setting CC to gcc 3.4.3 and rerunning configure:

checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes

The cc command line is also very simple all of a sudden:

configure:29748: checking for stdbool.h that conforms to C99
configure:29801: /usr/libexec/gcc34/gcc -c  -O2 -I/usr/local/include
conftest.c >&5

Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
Free Tibet! http://www.savetibet.org/ | http://ashemedai.deviantart.com/
http://www.tendra.org/   | http://www.in-nomine.org/
If slavery is not wrong, nothing is wrong...
-------------- next part --------------
--- configure.ac.orig	2005-02-20 17:58:22.000000000 +0100
+++ configure.ac	2005-02-20 18:04:28.000000000 +0100
@@ -29,7 +29,7 @@
 if test "$am_cv_func_iconv" != yes; then
-  AC_MSG_ERROR([Could not find iconv (required for uim)])
+  AC_MSG_ERROR([Could not find libiconv (required for uim)])

More information about the uim mailing list