This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR exp/9103


> * What to do about hosts without an iconv implementation.  There are
>   three choices:
> 
>   1. Require libiconv on such hosts
>   2. Like #1, but provide a simple way to drop libiconv into the src
>      tree.
>   3. Write a phony iconv-alike that only handles host charset ==
>      target charset, probably also providing "gdb_wchar_t" and various
>      other macros and whatnot to make it all work.

I am not completely opposed to (1).

The problem with this option is that it complicates the requirements
for building GDB. I remember that, not so long ago, I was keen on
trying out the latest and greatest of various programs (Debian usually
lags in the versions it ships, even with "testing". The problem was that
the list of dependencies was so big that I never managed to build
the program I was interested in within the amount of time that I allocated.
GDB is quite far from being that bad, but I personally tend to be sensitive
to these sort of issues. I'd like lambda people to be able to build GDB
relatively simply without having to have to double-check that certain
dependencies are met.

That's why I usually tend to favor option (3), especially if it's not
too much work to do. A slight variation of that option is what Daniel
did for libexpat. Certain features are simply not present unless
libexpat is available.

Otherwise, we need to look at how portable GNU libiconv is.
I don't expect any problem in that department, but then I was suprised
to see that libexpat seemed to be broken on AIX for me.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]