> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > The -liconv used to be there before in 7.1 and earlier. It was only
> > removed in September. Are you saying those system calls work for you,
> > but you don't have a libiconv?
>
> The <iconv.h> routines live in libc on HPUX. And on Red Hat Linux
> (I suppose also on other Linux flavors, but RHL 7.2 is the only one
> I have handy to check). And presumably on whatever platform Peter uses,
> else he'd not have removed the -liconv.
>
> Christopher has not yet opined on where they are on his platform...
> though since it's a BSD variant, it might be the same as yours.
>
> To fix this correctly we'd need to add configure tests for <iconv.h>
> and libiconv. I'm disinclined to do that, partly because it'd slow
> down configure for everyone whether they intended to build contrib/dbase
> or not, but mainly because in the present state of the build process
> it'd cause libiconv (if present) to be linked to *every* executable
> we build.
>
> I wonder if it's practical for contrib modules to have their own
> mini-configure checks above and beyond what the main configure script
> does?
>
> In the meantime, I don't really care that much whether dbase/Makefile
> contains -liconv or not; clearly, that will help some platforms and
> hurt others no matter which way we jump. I was just pointing out
> that your makefile change is not a clear win.
Yes, glad you pointed it out. I think the best solution is to remove
#define HAVE_ICONV_H and -liconv so it will work fine on all platforms.
If someone wants the iconv conversions, they can add the needed #define
and link library, OK?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026