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