On Wed, 30 Jul 2003 22:42:03 -0700 PDT "Andrew Bachmann" < shatty@xxxxxxxxxxxxx> wrote: [...] > 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) There shouldn't be a problem with using perl in our build system, if needed. > 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. Yep, for good reason, since otherwise you could cast consts away without the compiler noticing it Like: char *a; char **b = &a; const char **c = b; // nasty code const char *d = "Hello!"; *c = d; *a = 0; // here we write to d That's a bit unfortunate, for in some cases it seems to be a bit too strict, but we can't do anything about it (aside from doing a const_cast<>). > 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. We can as well build the `normal' version and write the <iconv.h> functions as simple wrappers for the GNU ones. > 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. 1. seems to be the option involving the least work. So, I would say, let's go for that. I would mind either of the alternatives concerning integrating the library into libroot or libtextencoding or have it stand alone. CU, Ingo