Re: [xml] Using libiconv

[Brian Stafford <brian stafford office-logic com>]

On Tue,  3 July 20:33 Tomasz Kłoczko wrote:

> Forgive me what is the sens using libiconv when you have iconv in glibc ?

Because libiconv is more comprehensive and less buggy than the libc's iconv.

> If someone have system with iconv in libc and additionaly have header
> files for libiconv this rather slightly not correct situacion and from    
> ths poin of view we can say "it is your private busines but this isn't
> correct" :)

I think libiconv's author would disagree with this point of view.

Libiconv serves two purposes.  It updates the one in GNU libc and
it provides iconv for platforms which do not have it at all.

> iconv detection IMHO can be performed as:
>
> 1) try find iconv in libc,
> 2) if not found in libc try find libiconv,
> 3) if not found libiconv system can't support iconv.

Because libiconv provides bugfixes and is more comprehensive wrt
character sets than the one in libc it should be used in preference
to the one in libc by default.  So the search order should be

1) try libiconv
2) try libc iconv
3) no iconv support

> --with{,out}-iconv can be used only for obligatory using or not iconv
> without depending on libc abilities or is libiconv is installed.

A --with-iconv option would be useful I agree, since it would allow
for people who have installed libiconv in a non-standard location
presumably to avoid clashing with the libc version.

In light of some of the stuff discussed in this thread, I will rework
my original patch to allow for a more bullet proof iconv test and to add
a --with-iconv option.


Regardless of the final solution, please bear the following in mind :-

I have libc from the original install of my Linux system.  I have
libiconv installed using the default paths from its configure.  But
in this scenario, the libxml2 configure script fails to detect the
necessary conditions to allow proper compiling and linking of libxml2.
In my opinion, that is a bug.

Regards
Brian Stafford