Summary: | configure finds no useful libiconv, actually on Mac OS X 10.4.7 | ||
---|---|---|---|
Product: | fontconfig | Reporter: | Peter Dyballa <Peter_Dyballa> |
Component: | library | Assignee: | Keith Packard <keithp> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | high | CC: | folti |
Version: | 2.3 | ||
Hardware: | PowerPC | ||
OS: | Mac OS X (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 8100, 12917 |
Description
Peter Dyballa
2006-08-03 12:23:26 UTC
Sounds like libiconv is required for Mac OS X; any chance you can hack up the configure to use it? 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) 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 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" (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 (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. 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.