[openbeos] Re: CVS: current/src/kits/support Jamfile,1.3,1.4

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

Other related posts: