Such a self-check routine would be particularly useful for the users
that build their own ICU and Boost!

I see clear reasons why a user not would want to go with your local
ICU+Boost build process in certain cases. For those cases, as a user you
want some kind of check on the way that doublechecks that ICU and Boost
actually work as they should with respect to ICU.

(Well - so perhaps in case LibBitcoin doesn't do it itself, just doing
two BIP39 runs from the user code with example passwords that should
give the same output, and check that they indeed give the correct
output, would suffice.)



On 2015-12-16 02:29, mlmikael wrote:
> 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.