apr-iconv is certainly ok as dependency on the desktop or server. My concern is adding another dependency on my resource constrained appliance.. both from the work involved (i am fundamentally lazy :-) ) and from the amount of space the library wants to consume on disk.
libapriconv.so is itself not to bad, but there are many many supporting libs in /usr/lib/iconv that I would need to prune as well. Looking at the apr-iconv code base, it actually just falls back to linux-iconv if it is found during autoconf. I am going to try both ways and push my changes to my github fork as I go. -- james * Holger Grandy <[email protected]> [2010-11-04 20:26:43 +0100]: > Hi James, > > cool! > > The original C binding implementation used Windows API functions to do > the character conversion. Since > we already had the dependency to the APR (for threads, mutexes, ...) > we changed that and extended that dependency to > apr-iconv. It works and is available across operating systems. We did > not want platform specific code in > the binding since we wanted to use it across plattforms with little > (best: no) porting effort. > > I guess the newer apr version should work, too. To my knowledge we do > not depend on specific features > of a version. 1.3.2 was just what was there when we started and we did > not yet find time to try it out > with other versions. > > I am very interested in your experiences! > > Cheers, > Holger > > On Thu, Nov 4, 2010 at 5:34 PM, James Dixson <[email protected]> wrote: > > Hey all, > > > > I am working on a project to cross-compile the c-binding for ARM for use > > in an embedded linux appliance. A couple of questions: > > > > 1) has anyone attempted this yet? > > 2) I notice the use of apr-iconv. Is there any technical reason why > > apr-iconv is required for linux vs. iconv that is native to glibc? I > > would like to #ifdef around the code to use apr-iconv when needed (on > > windows) but glibc-iconv on linux. > > 3) Are there any technical reasons for the specific versions of apr and > > cunit referenced in the c-binding or will later versions work as well > > (assuming no api changes of course). > > > > -- > > james > > > >
