I'm jhbuilding fontconfig on solaris, and fontconfig can't seem to handle the
native iconv. A patch to fix this is at
Someone from Sun says that it works fine... can you comment?
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
- 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]
Committed. Tim (and others), please verify as you are able to. Thanks all!
+ # try using libiconv
+ LIBS="$LIBS -liconv"
+ AC_TRY_LINK([#include <iconv.h>],
+ [iconv_open ("from", "to");],
+ if test x$use_iconv = x1; then
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
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.
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.
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...