I've tried to use AM_ICONV instead, indeed, it may works as you
expected and actually it does. however it also introduces the RPATH
issue too. need to think about it more. just FYI.
On Sat, Dec 22, 2012 at 3:46 PM, Daniel Macks <dmacks@xxxxxxxxxxxx> wrote:
> On OS X, iconv.h is in a default search path (no need for -I flags); but is not part of the system library itself,so -liconv is needed (but again is in default search path so no need for -L flags). There are a bunch of special-purpose --with-libiconv* flags, but there doesn't seem to be an easy way to handle my situation. If I understand the if/elif spaghetti, I need to declare an explicit libiconv prefix or includes directory in order for libiconv_cflags to be set, which is the only way to trigger libiconv_libs getting set. Or else I need to pass LDFLAGS=-liconv to the whole build process.
>
> "See if libiconv is available, possibly with some ./configure flag hints" is a common task with standard (in autoconf or in libiconv) recipes. For portability, hand-coding seems fragile, and ease of use ("behaves like other packages that use libiconv") also suffers. For example, libiconv's iconv.m4 has a AM_ICONV function.
>
> dan
>
> --
> Daniel Macks
> dmacks@xxxxxxxxxxxx
>
> _______________________________________________
> Fontconfig mailing list
> Fontconfig@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/fontconfig
--
Akira TAGOH
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
