On Thu, 31 Jul 2003 04:14:09 +0200 CEST "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote: > Andrew Bachmann <shatty@xxxxxxxxxxxxxxxxxxxxx> wrote: > > need libiconv.so for new libtextencodings.so to work > > Do we want to have a separate libiconv.so later in OpenBeOS? > Or as part of libroot.so? Or as part of libtextencoding.so? Ah.. I don't know how this email snuck past my sensors. This is a question that I also wanted to pose as part of the earlier mess. I think in principle I prefer the combination of more, smaller libraries and linking libraries to libraries. So I suppose it's no surprise that I linked libtextencoding.so to libiconv.so. Presumably we are going to expose iconv since it is in our headers. The interface for iconv is very similar to that for convert_to/from_utf8. The convert functions provide a piece of additional functionality which is to insert a user-specified character when no target character exists in the destination. This is rather silly for convert_to_utf8 since unicode is intended to be all-encompassing. For the conversion back I have not implemented the substitution functionality. It's not clear how iconv handles it when there is no suitable destination character. This may warrant some testing. (and more expertise about encodings than I have) I should note that if we have a separate libiconv.so the way that I envision it (with the iconv_open API instead of libiconv_open for example) then the library will not be substitutable for the default gnu build. This is annoying, but in my opinion it's the default gnu build that's really broken here. It's not a very happy situation. Perhaps we should entertain the idea of fixing the gnu build so it does "the right thing" on beos? Then we could get substitutability and header interchangability - almost. There's still the const char** issue. Andrew