Re: [PATCH/WIP] C/C++ wchar_t/Unicode printing support

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Tom> * With this patch, GDB requires iconv.  I don't think it is a good use
Tom> of our time to implement and maintain our own character set
Tom> conversion library.  I removed all the old code in charset.c that
Tom> attempted this.

Joel> External dependencies of this sort can be a real issue.

Yeah.  Daniel pointed out the expat thread while we were discussing
this; I think that shows most of the issues.

Joel> In other words, when we distribute a GDB binary to one of our
Joel> customers, we pretty much need to distribute the iconv library
Joel> as well.

We could try updating src/configure to let builders in your situation
drop GNU libiconv into the tree.  Would this work for you?  How do you
handle expat?  And how do you plan to handle python?

Joel> Do you think we could have a configure option that allows us to
Joel> deactivate this feature in order to avoid the dependency?

I don't think it would be very easy to make this an optional feature,
or to make it fall back to the currently existing code.

I suppose one option would be to have a degraded mode where we require
that the host charset and the target charset be the same.  Then maybe
we could make it work by redefining iswprint and wchar_t.

However, before doing that it would be good to know whether that is
actually useful for anybody.

I don't think it would be very easy to preserve the current
functionality and make the iconv stuff an add-on.  The current charset
API is not well suited to variable length encodings.

It would also be nice to know more about the state of iconv on various
hosts -- I haven't paid attention to this in a number of years, and
for all I know all the vendors got their acts together.  I don't have
ready access to anything other than Linux these days, so someone else
would have to look into this.

Tom