Bug 7758 - configure finds no useful libiconv, actually on Mac OS X 10.4.7
Summary: configure finds no useful libiconv, actually on Mac OS X 10.4.7
Status: RESOLVED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.3
Hardware: PowerPC Mac OS X (All)
: high normal
Assignee: Keith Packard
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 8100 12917
  Show dependency treegraph
 
Reported: 2006-08-03 12:23 UTC by Peter Dyballa
Modified: 2007-10-25 08:27 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Peter Dyballa 2006-08-03 12:23:26 UTC
config.log contains:

configure:20654: checking for a usable iconv
configure:20673: gcc -o conftest -g -O2 -I/sw/lib/pango-ft219/include -I/sw/include/pango-1.0 -I/
usr/local/include/freetype2 -I/sw/include/libpng12 -I/usr/local/include -I/sw/include -dead_strip -L/
usr/local/lib -L/sw/lib/ncurses -L/sw/lib/pango-ft219/lib -L/usr/lib -L/sw/lib conftest.c  >&5
/usr/bin/ld: warning prebinding disabled because of undefined symbols
/usr/bin/ld: Undefined symbols:
_libiconv_open
collect2: ld returned 1 exit status
configure:20679: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "fontconfig"
| #define VERSION "2.3.95"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #ifdef __cplusplus
| extern "C" void std::exit (int); using std::exit;
| #endif
| #define HAVE_DIRENT_H 1
| #define STDC_HEADERS 1
| #define HAVE_FCNTL_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_VPRINTF 1
| #define HAVE_STDLIB_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_GETPAGESIZE 1
| #define HAVE_MMAP 1
| #define HAVE_GETEUID 1
| #define HAVE_GETUID 1
| #define HAVE_LINK 1
| #define HAVE_MEMMOVE 1
| #define HAVE_MEMSET 1
| #define HAVE_MKSTEMP 1
| #define HAVE_STRCHR 1
| #define HAVE_STRRCHR 1
| #define HAVE_STRTOL 1
| #define HAVE_GETOPT 1
| #define HAVE_GETOPT_LONG 1
| #define HAVE_SYSCONF 1
| #define HAVE_FTRUNCATE 1
| #define HAVE_RAND_R 1
| /* end confdefs.h.  */
| #include <iconv.h>
| int
| main ()
| {
| iconv_open ("from", "to");
|   ;
|   return 0;
| }
configure:20726: gcc -o conftest -g -O2 -I/sw/lib/pango-ft219/include -I/sw/include/pango-1.0 -I/
usr/local/include/freetype2 -I/sw/include/libpng12 -I/usr/local/include -I/sw/include -dead_strip -L/
usr/local/lib -L/sw/lib/ncurses -L/sw/lib/pango-ft219/lib -L/usr/lib -L/sw/lib conftest.c  -liconv >&5
configure:20732: $? = 0
configure:20735: test -z 			 || test ! -s conftest.err
configure:20738: $? = 0
configure:20741: test -s conftest
configure:20744: $? = 0
configure:20761: result: no

Executing the compile command on the command line creates an executable binary that uses

	/usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0)

When executed it returns 0. Nm shows this contents of /usr/lib/libiconv.2.dylib:

	nm -p /usr/lib/libiconv.2.dylib | grep iconv_open
	92d75058 T _iconv_open
	92d7475c T _libiconv_open

In the end libfontconfig.1.0.4.dylib is built, not prebound and using these other libraries:

src/.libs/libfontconfig.1.0.4.dylib:
	/usr/local/lib/libfontconfig.1.dylib (compatibility version 2.0.0, current version 2.4.0)
	/usr/local/lib/libfreetype.6.dylib (compatibility version 10.0.0, current version 10.10.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
	/usr/local/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.6)

Is libiconv needed for libfontconfig or is it necessary to work on this item?

./configure --with-freetype-config=/usr/local/bin/freetype-config CPPFLAGS="-I/sw/lib/pango-ft219/
include -I/sw/include/pango-1.0 -I/usr/local/include/freetype2 -I/usr/local/include -I/sw/include" 
LDFLAGS="-dead_strip -L/usr/local/lib -L/sw/lib/ncurses -L/sw/lib/pango-ft219/lib -L/usr/lib -L/sw/
lib" (no CFLAGS yet set)
gcc 4.0.1
Comment 1 Keith Packard 2006-09-01 12:38:58 UTC
Sounds like libiconv is required for Mac OS X; any chance you can hack up the
configure to use it?
Comment 2 Peter Dyballa 2006-09-02 08:44:01 UTC
Does it help to name some projects that detect libiconv?

atk1            1.12.1-2        Accessability Toolkit
gd2             2.0.33-3        Graphics generation library
gettext         0.10.40-25      Message localization support
glib            1.2.10-51       Common C routines used by Gtk+ and other libs
gtk+            1.2.10-51       The Gimp Toolkit
gtk+2           2.6.10-1001     The Gimp Toolkit
libgettext3     0.14.5-2        GNU Internationalization utils (shared libs)
libxml2         2.6.26-1001     XML parsing library, version 2
libxslt         1.1.17-1        XML stylesheet transformation library
pango1-xft2     1.10.1-1001     GTK+ - i18n libs (for XFree86 >= 4.3)
scrollkeeper    0.3.14-6        Cataloging system for documentation

What I can do is to test an augmented configure script on my Mac. I have no practise in writing a 
configure script, I am only used a bit to debug such a script ...

Nevertheless, in August I had to update Fink! (It's my "provider" for libiconv.) In this updated software 
environment configuration now succeeds. The only problem left in this situation, is that the freshly made 
fc-list crashes when invoked as fc-list/.libs/fc-list. Probably this happens because libfontconfig is not 
yet available in /usr/local/lib. This is a flaw in Mac OS X: "Since Mac OS X uses full paths for libraries 
instead of searching, rpath is less interesting." (install_name_tool might allow to correct this by adding 
@loader_path/... to the path where libraries can be found)

I'd think the reported bug is solved ... The installed programmes seem to work (a bit, probably I am 
missing some reading, and how to make old and nex fc-list co-exist)
Comment 3 paul 2006-12-17 12:01:06 UTC
when i made my recent comments in bug #4083, i was thinking about this specific
bug and i think it clears up the problem

[shadesofgray:/private/tmp] paul% nm /usr/lib/libfontconfig.dylib | grep iconv
         U _libiconv
         U _libiconv_close
         U _libiconv_open
Comment 4 Tamas Pal 2007-07-05 09:06:22 UTC
Hello,

I ran into this problem compiling fontconfig 2.4.2 on windows.

It turned out that the cause of the problem is a programming error in configure.
The second AC_TRY_LINK(line 184) fills the use_iconv variable with true/false
but the following test checks for 1.

# configure.in:184:
	AC_TRY_LINK([#include <iconv.h>],
		    [iconv_open ("from", "to");],
		    [use_iconv=true],
		    [use_iconv=false])
	
	if test x$use_iconv = x1; then
		ICONV_LIBS="-liconv"
		AC_MSG_RESULT([libiconv])
	else
		AC_MSG_RESULT([no])
	fi

After fixing this, the new configure detects iconv properly.

One possible solution:
--- orig/configure.in	2007-07-05 19:38:51.000000000 +0200
+++ mod/configure.in	2006-12-03 00:24:39.000000000 +0100
@@ -186,8 +186,8 @@
 
 	AC_TRY_LINK([#include <iconv.h>],
 		    [iconv_open ("from", "to");],
-		    [use_iconv=1],
-		    [use_iconv=0])
+		    [use_iconv=true],
+		    [use_iconv=false])
 	
 	if test x$use_iconv = x1; then
 		ICONV_LIBS="-liconv"
Comment 5 Peter Dyballa 2007-07-06 10:22:30 UTC
(In reply to comment #4)

I think you need to patch some more occurrences! And the other way 'round!!

I tried your patch, now on Mac OS X 10.4.10, with fontconfig 2.3.95 and 2.4.0 – without success. Then I looked at config.log and found that the variable use_iconv is the important item:

	157:	    [use_iconv=1],
	158:	    [use_iconv=0])
	159:if test x$use_iconv = x1; then
	168:		    [use_iconv=true],
	169:		    [use_iconv=false])
	171:	if test x$use_iconv = x1; then
	181:AC_DEFINE_UNQUOTED(USE_ICONV,$use_iconv,[Use iconv.])

So it seems that the lines #168 and #169 need to be changed to 1 resp. 0 that the test in line #171 can succeed. I made that change – and nothing changed. How can I propagate chnages in configure.in to configure? When I changed the configure script

	22146:  use_iconv=1
	22151:	use_iconv=0
	22156:if test x$use_iconv = x1; then
	22213:  use_iconv=1
	22218:	use_iconv=0
	22224:	if test x$use_iconv = x1; then
	22238:#define USE_ICONV $use_iconv

I finally *had* succes during configuration:

	checking for a usable iconv... libiconv
Comment 6 Tamas Pal 2007-07-07 11:47:58 UTC
(In reply to comment 5)

I'm sorry, i've managed to copy a reverse patch into comment 3... :( 
The correct patch will look like this:

--- orig/configure.in   2007-07-05 19:38:51.000000000 +0200
+++ mod/configure.in    2006-12-03 00:24:39.000000000 +0100
@@ -186,8 +186,8 @@

        AC_TRY_LINK([#include <iconv.h>],
                    [iconv_open ("from", "to");],
-                   [use_iconv=true],
-                   [use_iconv=false])
+                   [use_iconv=1],
+                   [use_iconv=0])

        if test x$use_iconv = x1; then
                ICONV_LIBS="-liconv"

It'll teach me (again) to check my patches before sending them... :/

You can re-generate configure by running autoconf in configure.in's directory.
AFAIK if you don't have it, you can install it using Fink!. With it's companion 
packages automake and libtool(not always needed) they are used to (re)build the
configure script and the Makefile.in's(makefile stubs filled in by configure).
Even if you don't use them, they are worth having on a developer machine.
Comment 7 Behdad Esfahbod 2007-10-25 08:18:26 UTC
Keith, this one's fixed too, right?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.