Bug 4083 - fontconfig needs configure option to use gnu iconv
Summary: fontconfig needs configure option to use gnu iconv
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.3
Hardware: SPARC Solaris
: high normal
Assignee: fontconfig-bugs
QA Contact: Behdad Esfahbod
URL: http://jhbuild.bxlug.be/builds/2006-0...
Depends on:
Reported: 2005-08-15 01:33 UTC by James Andrewartha
Modified: 2012-04-10 05:58 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

patch (2.98 KB, patch)
2006-04-25 21:19 UTC, Behdad Esfahbod
Details | Splinter Review
diff to catch libiconv properly (364 bytes, patch)
2006-12-17 10:03 UTC, paul
Details | Splinter Review

Description James Andrewartha 2005-08-15 01:33:06 UTC
I'm jhbuilding fontconfig on solaris, and fontconfig can't seem to handle the
native iconv. A patch to fix this is at
Comment 1 Patrick Lam 2006-03-04 07:31:51 UTC
Someone from Sun says that it works fine... can you comment?

Comment 2 James Andrewartha 2006-04-20 03:41:40 UTC
It's still broken, see new URL. My patch from before doesn't fix it this time.
Comment 3 Patrick Lam 2006-04-20 04:16:51 UTC
I'd like to get fixes for the iconv family of bugs into 2.3.95.  What version of
solaris are you using?

Your URL doesn't show -liconv on the command line.  It's almost like your patch
didn't take or something.  If you add -liconv explicitly, does it help?
Comment 4 Tim Mooney 2006-04-22 09:40:17 UTC
FYI I just tried CVS from the fc-2_4-branch (it's already listed as 2.3.95 in
the ChangeLog), and it builds out of the box on Solaris 10 with the Sun Studio
compiler and the system (libc) iconv.

If I get a chance, I'll try with GNU libiconv later tonight.
Comment 5 Tim Mooney 2006-04-22 10:48:45 UTC
Trying with GNU libiconv 1.9.2 installed, I do see the link problems.  It's
pretty much as others have described:

- if you have GNU's iconv.h installed, that remaps all the function names
  to the libiconv* names that the GNU library uses.

- configure.in is currently testing whether iconv.h can be included (it can)
  and whether AC_CHECK_FUNCS([iconv]) works, and it does, because there's an
  iconv in libc.  The problem is that AC_CHECK_FUNCS doesn't include any 
  headers, so it's not a true test of whether your iconv.h and iconv
  function names match.  That's where the problem is coming; once iconv.h
  is included from GNU iconv, we no longer need symbols like iconv_open, we
  need libiconv_open().

- the easiest way to do a true test is to try an AC_TRY_LINK of a small program
  that both includes iconv.h and calls iconv_open().  If that *fails*, we
  either don't have any iconv at all, or we have GNU iconv.h but we haven't
  yet added -liconv to the LIBS.

  So, if it fails, we then try an AC_CHECK_LIB([libiconv, [libiconv_open]).
  If that succeeds, we again AC_TRY_LINK.  If it fails, we can't find any
  iconv. If it succeeds, we have GNU iconv.h and GNU libiconv.  We just need
  to get -liconv substituted into the dependencies for libfontconfig.la.

If any of the fontconfig maintainers are autoconf and automake wizards, I'm sure
you can construct the tests based on my comments.  If not, I can write them, but
it will probably take a little longer.  I'm good with simple autoconf tests,
but I'm rusty with the more complicated stuff (and automake).

Let me know if you want me to write the tests.  Otherwise, I'll assume I should
just plan to test them when one of you writes them.
Comment 6 Patrick Lam 2006-04-24 08:12:51 UTC
Thanks, I've asked Behdad Esfahbod to create a patch.
Comment 7 Behdad Esfahbod 2006-04-25 21:19:40 UTC
Created attachment 5469 [details] [review]
Comment 8 Patrick Lam 2006-04-26 01:33:56 UTC
Committed.  Tim (and others), please verify as you are able to.  Thanks all!
Comment 9 Patrick Lam 2006-04-26 01:34:12 UTC
Marking FIXED.
Comment 10 paul 2006-12-17 09:52:47 UTC
+	# try using libiconv
+	fontconfig_save_libs="$LIBS"
+	LIBS="$LIBS -liconv"
+	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
+	LIBS="$fontconfig_save_libs"

if test x$use_iconv = x1; then
needs to be 
if test x$use_iconv = xtrue; then
otherwise, iconv isn't recognized as being there
Comment 11 paul 2006-12-17 10:03:05 UTC
Created attachment 8148 [details] [review]
diff to catch libiconv properly

in keeping with the 1s and 0s of a config.h file, this is better
Comment 12 paul 2006-12-17 10:44:46 UTC
comment required to reopen a bug
Comment 13 Behdad Esfahbod 2007-10-25 08:27:10 UTC
Fixed yesterday.
Comment 14 Martin Trautmann 2009-01-13 05:06:47 UTC
It's still - or once again - not working.

gcc -g -O2 -o .libs/fc-cache fc-cache.o  ../src/.libs/libfontconfig.so -L/scratch/.linux/lib /usr/local/lib/libfreetype.so-lz /usr/lib/libexpat.so  -Wl,--rpath -Wl,/usr/local/lib
../src/.libs/libfontconfig.so: undefined reference to `libiconv_open'
../src/.libs/libfontconfig.so: undefined reference to `libiconv_close'
../src/.libs/libfontconfig.so: undefined reference to `libiconv'

Current setup: fontconfig-2.6.0, libiconv-1.12

/usr/local/include/iconv.h names _LIBICONV_VERSION 0x010B

I added -liconv manually to ICONV_LIBS or LDFLAGS within the Makefile, which did not make any difference.
Comment 15 Andrew SG Rojek 2009-09-02 22:03:53 UTC

I encountered the same problem on an iMactel machine building
the 64 bit package [fontconfig 2.7.2]. It seemed to compile OK
for 32 bit as far as I can tell.

As I had to install a more up-to-date version of libiconv, I had to tell
the compiler where the new library was with -I and -L. Freetype then
built as expected and so did fontconfig.

Regarding comment 14, it may well be that the script that builds the
library was libtool (where my error occurred) and not a makefile. 
However, making changes to either didn't change the outcome for me.

Comment 16 Akira TAGOH 2012-04-10 02:51:19 UTC
should be better in git repo now. use --with-libiconv or --with-libiconv-includes and --with-libiconv-lib to specify the directory. please try and reopen if you still see this issue. thanks
Comment 17 Behdad Esfahbod 2012-04-10 05:58:16 UTC
May be about time to remove support for non-Unicode fonts anyway...

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.