Well... As of ICU-4.2, the names of the libraries are documented here: http://userguide.icu-project.org/icufaq#TOC-How-do-I-install-the-binary-vers... and match what the Jamfile assumes (and what I downloaded in the binary package), this information: http://source.icu-project.org/repos/icu/icu/tags/release-4-2-1/readme.html#H... also uses the same filenames, for example icuin.lib/dll and not icui18n.lib/dll.
Um, the problem isn't that the build system wanted icuin and got given icui18n etc, it's the other way round. It wants icu18n & icudata, and is given icuin & icudt instead. if $(HAVE_ICU) { gHAS_ICU = true ; gICU_CORE_LIB = icuuc ; gICU_IN_LIB = icui18n ; gICU_DATA_LIB = icudata ; gICU_CONFIG_CHECKED = true ; }
The else if clause right below that is kinda complicated and I'm not entirely following it, but it seems the build system is following two different path both building with ICU when ICU_PATH is set depending on whether HAVE_ICU is set. (My reading of the documentation suggest setting -sHAVE_ICU=1 to build with ICU.)
As a test, I just downloaded the latest ICU 4.2 binary on Windows with VC9 and attempting to build using trunk, setting -sHAVE_ICU=1 -sICU_PATH="...". ...failed updating 5 targets... ...skipped 6 targets... ...updated 47 targets... When only ICU_PATH is set, it builds fine. ...updated 58 targets...
OK I'll look into that some more: however the intension was that HAVE_ICU and ICU_PATH should not be mixed, HAVE_ICU is designed for Unix like systems that have the icu binaries installed in the usual std locations under the std Unix naming convention for ICU. I'll try and tweak the logic so that ICU_PATH takes precedence in that case. Thanks, John.