[openbeos] suggestions: iconv.h, libiconv, and iconv

Hello all,

I recently completed the first implementation of libtextencoding.so, with the 
BCharacterSet, 
BCharacterSetRoster, convert_to_utf8, and convert_from_utf8.  I used the posix 
standard 
functions from iconv.h.  I was able to zip up the R5 libtextencoding.so and 
perform such fun tasks 
as read japanese encoded files, unicode 2.0 encoded files, etc.  It does look 
like there are some 
issues with net+ that I have to look at.  But that isn't the reason for this 
email.

I ported the GNU libiconv 1.9.1 recently.  (it's on bebits)  I used it to build 
libtextencoding.so and 
test it.  This went pretty well.  Using a configure flag I was able to build a 
version of libiconv that 
supported all of the conversions that are in UTF8.h.  However, when I went to 
build 
libtextencoding.so I ran into a nasty.  "undefined reference to `iconv_open'", 
etc.  I went and 
looked and I found out that the gnu iconv.h rudely #define's iconv_open to 
libiconv_open.  
When I built libiconv, it used it's own iconv.h  When I built 
libtextencodings.so it used our iconv.h 
from headers/posix.  In my opinion here, it's GNU's brain damage that they 
export the symbols as 
libiconv...  And this particular bug is actually easy to fix although it 
requires rebuilding libiconv. 
(annoying)

Anyway, I was thinking LGPL and all that and I also realized "hey, FreeBSD has 
an iconv 
implementation! let's go check that out".  So I trucked over to freebsd and 
grabbed their "iconv" 
package.  I downloaded it and went to build, and what the heck is going on?  
The makefiles are 
all written in some gobbledygook makefile language that gnumake don't grok. 
(and neither do I)  
So that was quite annoying.  I worked at it for a bit converting the makefile 
to jamfiles.  In the 
midst I ran into another nasty.  FreeBSD's build system uses perl scripts to 
autogenerate the 
tables.  (ugg)

At this point I decided to go back to the gnu one since I at least got that 
fully built.  That's when I 
noticed another nasty. (is there no end to them?)  The GNU version of iconv.h 
declares the 
function iconv's second argument as a const char ** instead of a char **.  You 
wouldn't think it'd 
be much of a deal to pass a char ** into a const char ** function but at least 
my compiler doesn't 
like it.  It says: "passing `char **' as argument 2 of `iconv' adds cv-quals 
without intervening 
`const'".  Yuck! So, although the gnu header has a sort of enlightened argument 
list in that it 
simply promises to less damage, the compile fails.

So, I'm stuck in what I view to be a poor situation.  Right now we have what I 
consider to be a 
perfectly fine, ideal version of iconv.h checked in. (after I added size_t.h 
anyway)  However, 
using this header, you can't link to the libiconv.so from gnu. (doh!)  If we 
replaced our perfectly 
good header with the messy gnu iconv.h then we get a compiler error on (what I 
think is) posix-
ok code. (doh!)  Now it seems like the FreeBSD library may be able to save the 
day.  But to build 
it requires decyphering freebsd make and also having perl around to run build 
scripts. (doh!)  
The FreeBSD iconv also has the second argument const char **, but at least we 
don't have to link 
against that header since it properly exports the functions by their rightful 
names. (as far as I can 
tell so far since I haven't got it building yet)

So, I'm quite mystified here.  Can I get some opinions or observations?  In my 
opinion we should 
stick to the posix definition of iconv's argument list, and as far as I can 
tell that means no const.  
We also should publish the symbol from our libiconv.so as iconv, and not as 
libiconv.  Right now I 
see three options:

1. Build the so-called "plugin" version of gnu libiconv.so [this version 
publishes the API as 
iconv_open and not libiconv_open], and publish it as libiconv.so.  This is 
possible by modifying a 
makefile slightly and manually requesting the plugin version.
2. Decypher the FreeBSD build system and use their libiconv.so.  This may 
involve either 
checking in perl-generated files, or requiring perl to build.  In any case it 
will require some 
effort and would probably be best done by someone familiar with their build 
system or at least 
with access to a box that has freebsd installed.  A rather significant drawback 
of this approach in 
my opinion is that it may be difficult to update our "version" when the FreeBSD 
one gets 
updated.
3. Do something else.

Thoughts?

Andrew

Other related posts: