I couldn't help but notice that you were talking about ICU on this mailing list. Let me interject with some suggestions.
Thanks much for the message.
I should mention that ICU 2.6 can build a static data library. I recommend that ICU be built without the --with-data-packaging=archive configure option. You will probably have fewer path issues if you did that, and used ICU static data library.
I went with the --with-data-packaging=archive initially for 3 pragmatic reasons: (1) it seems to take a really, really long time to build them into a library, and (2) once parrot "ships", if we use --with-data-packaging=archive or --with-data-packaging=files then that would permit end users to add/remove encoding without needing access to a compiler, and (3) our automated tests end up linking in our libraries, so building the ICU data as a static library slows this down significantly, since it has to copy around all of the bits for each test.
But (1) and (3) are just short-term, convenient-for-ongoing-development reasons.
Long term, it make sense to expose all of the packaging choices to the parrot build-configuration process, and let "end users" decide what's best for them.
In the short term, this is having the nice side effect of forcing some issues of resource location that we'll need to solve for other resources anyway.
If you are having problems and need to patch ICU, you should consider submitting the patches to ICU to our jitterbug system <http://www.jtcsv.com/cgibin/icu-bugs>.
I have a few (bugs if not patches) to submit. (For instance, with ICU 2.8, building the tools seems to fail in the case of --enable-static --disable-shared, because of the "s" prefix.) I'll be in touch!
Thanks again,
JEff
