Re: [RFC] --with-iconv-path

[Doug Evans <dje@google.com>]

On Fri, May 6, 2011 at 8:12 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> We have one environment where the iconv binary comes from a
>> non-standard location.  This patch lets one tell gdb where to find it.
>
> Does it mean that the libiconv libraries are at one location, and
> that the binary is at a different location? Looking at your patch,
> it looks like you might have a situation where the name of the iconv
> binary itself is different...

There is no libiconv library, there's just iconv_{open,close,} in
glibc and the iconv binary.

>> 2011-05-05  Doug Evans  <dje@google.com>
>>
>>       * configure.ac: New configure option --with-iconv-path.
>>       * configure: Regenerate.
>>       * config.in: Regenerate.
>>       * charset.c (find_charset_names): Use ICONV_PATH if defined.
>
> "path" had me confused, and made me think that you were going
> to pass the name of the directory where iconv is located. But
> the patch seems to be contradicting that.
>
> If we don't need to specify the name of the iconv directory,
> then perhaps we could just focus on the directory name itself.
> We could even make that directory name relatocatable, the same
> way we make some of the paths relocatable as well.
>
> Normally, we have sets of switches that look like this:
>
>        --with-xxx=PATH
>        --with-xxx-lib=PATH
>        --with-xxx-include=PATH
>        etc
>
> We already have --with-libiconv-prefix.  So, how about naming it
> --with-libiconv-bin ?
>
> If we think that it would be convenient to specify the iconv exe
> as well, how about --with-libiconv-exe or --with-libiconv-program?

--with-libiconv-{bin,exe} "works for me"

For reference sake, the binary lives in the expected location given
--with-libiconv-prefix (i.e., bin/iconv), but how do I effect the
necessary change without breaking anything.

If folks are happy with adding $WITH_LIBICONV_PREFIX/bin to the front
of the search path instead (so no new configure option), I can do
that.
Seems reasonable, but I guess it *could* break someone's installation somewhere.
OTOH, if people are passing --with-libiconv-prefix they may have
iconvlist() in which case the iconv binary isn't used, so we're safe.