Ah, so, LibBitcoin uses ICU *through* Boost. So then, ICU must be
installed, and the ICU version must be satisfactorily new, and, Boost
must be compiled to use that ICU version and none other.

I understand that it took an eternity to finally get to the conclusion
that the most straightforward thing is to build your own local ICU and
Boost and link them in statically. It's almost comical how foolproof
that way of doing it is (at least in that particular respect).


Now, I know that the BIP 39 code will throw an exception if it's invoked
and LibBitcoin was compiled without ICU.

But, what if LibBitcoin was compiled "with ICU" but some aspect of it
was broken (e.g. Boost didn't actually link to ICU, or ICU was too old,
or something else) -

Is there any code within the build process, or at LibBitcoin load time,
that checks that it's actually healthy -

Or can I do anything like "assert
bip39_check_that_the_icu_support_is_healthy();"?


I mean, just so that the whole thing is foolproofed. Just to be sure
that nothing in that whole chain of things that could be broken, is
broken.

Maybe then that health check should do a whole BIP39 run for 2-3 example
input strings with content that should normalize to one and the same
string, and then checking that all of them give the same output. If
that's all that all of libbitcoin* uses ICU for.

On 2015-12-15 14:47, Eric Voskuil wrote:
> The installer uses v55.1:
>
> https://github.com/libbitcoin/libbitcoin/blob/master/install.sh#L36
>
> I'm not sure if this is the absolute minimum. The dependency is
> indirect
> (via boost), and I don't recall what is documented or if I tested all
> available options. But I usually do attempt to work with the lowest
> possible dependency version.
>
> However, the version itself may not be sufficient. I had little luck
> getting preinstalled versions of ICU to work on either OSX or Ubuntu.
> On
> Windows boost uses native Unicode features, so there is no ICU
> dependency.) It seems that the normalization features are not always
> installed.
>
> Compounding this issue is that boost ICU discovery is a bit of a hack,
> and it assumes an ICU directory structure that's outdated. There is a
> hack (to the boost installer) in the install.sh to overcome this.
>
> Compounding this even further is that the boost-locale build with ICU
> required, will compile even if these normalization APIs are missing.
> And
> then invoking the boost normalization API will also succeed, but it
> will
> not perform the normalization - just passing the text straight
> thorough.
> So we have a unit test to verify, bust also a first-run test to ensure
> the API is linked and working properly. Otherwise people could lose
> money by mismatching passphrases in the case where they didn't
> run/notice unit test failures.
>
> I spent at least a week on getting the ICU dependency reliable on
> across
> all platforms. It's a nightmare I don't plan to revisit for some time
> :).
>
> e
>
> On 12/14/2015 09:53 AM, mlmikael wrote:
>> (As for me I use http://icu-project.org/apiref/icu4c/ version 55.1 .)
>>
>> On 2015-12-15 01:46, mlmikael wrote:
>>> "libbitcoin"'s README.md mentions that libICU is "not typically
>>> preinstalled at a sufficient level".
>>>
>>> (https://github.com/libbitcoin/libbitcoin/blob/version2/README.md)
>>>
>>> How can I determine if my OS' bundled libICU is satisfactory?
>>>
>>> Thanks!
>>> Mlmikael
>>>
>>> _______________________________________________
>>> Libbitcoin mailing list
>>> Libbitcoin@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>
>> _______________________________________________
>> Libbitcoin mailing list
>> Libbitcoin@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin