Topic: wxWidgets 2.9.0 (Read 13628 times)
Looking through the source of 2.8.10 it appears that unicode is possible with that version too.
In the Windows world, "unicode" means UTF-16 (wchar).2.8 has two build variations, ANSI and UTF-16 (unicode). The UTF-16 version is the "unicode" version provided in the Debian package. I believe 2.8 and its UTF-16 build labelled simply "unicode" has been the source of build problems described in the forum. We were previously using 2.8 ANSI in anticipation of getting to UTF-8 without going through UTF-16 hell. We cannot compile with UTF-16.
2.9 has only one version, UTF-8. On Windows, we set the codepage to UTF-8, so on all platforms our code is UTF-8 and wxWidgets interfaces with us in UTF-8. On Linux I assume the codepage is already UTF-8. By standardizing on 2.9 we avoid the multi-build confusion of 2.8, and we need 2.9 for UTF-8 internationalization.
Make sure you read build-unix.txt and configure wxWidgets using the configure parameters given.
Curious, why is it incredibly hard to provide wxWidgets 2.9.0? If you mean for users, that's why we static link it.
It's unfortunate that we require so many big dependencies, but we need them all. At least on Debian/Ubuntu, all but wxWidgets are available as packages. Eventually they'll provide a 2.9 package.
I'm currently trying to get BitCoin to compile on the openSuse Build Service, which would allow us to create a wide range of precompiled packages for a variety of distros but I'm continually running into problems. The most important of them is the wxWidgets 2.9.0 requirement which is incredibly hard to provide, and the source of many of the problems described on the Forum. Why is it so important to have a 2.9.0? Looking through the source of 2.8.10 it appears that unicode is possible with that version too.
Regards,
cdecker
Regards,
cdecker
Jump to: