Someone from Sun says that it works fine... can you comment?

http://lists.freedesktop.org/archives/fontconfig/2006-March/002161.html

It's still broken, see new URL. My patch from before doesn't fix it this time.

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?

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.

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.

Thanks, I've asked Behdad Esfahbod to create a patch.

Created attachment 5469 [details] [review]
patch

Committed.  Tim (and others), please verify as you are able to.  Thanks all!

Marking FIXED.

+	# 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

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 required to reopen a bug

Fixed yesterday.

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
/usr/local/lib/libiconv.so.2.4.0


I added -liconv manually to ICONV_LIBS or LDFLAGS within the Makefile, which did not make any difference.

Hi,

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.

A.

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

May be about time to remove support for non-Unicode fonts anyway...