On Sun, Oct 01, 2006 at 03:28:20PM +0200, Georg Baum wrote: > Am Sonntag, 1. Oktober 2006 14:46 schrieb Enrico Forestieri: > > > The problem here is that sizeof(wchar_t) is 2 on cygwin and uint32_t > > cannot be used due to missing specializations in STLPort. I am not > > able to fill the missing bits in the Georg's work (after all, I am a > > sorcerer's apprentice :) ) but succeeded in hacking STLPort such that > > uint32_t can be used in place of wchar_t. > > That does not work. You are now using a 4byte character type, but the > internal stlport functions such as std::ctype::to_upper do still assume a > 2byte encoding. Therefore you cannot store 4 bytes in uint32_t, and it > would have been easier to just use a 2byte wchar_t instead of patching > stlport.
I don't understand this. I am compiling the library by replacing everywhere wchar_t with uint32_t, so this would be also true on a system where wchar_t is 4 bytes. The _STLP_WCHAR_T_IS_USHORT define simply serves the purpose of avoiding duplicate definitions (it plays the same role of _WCHAR_T_DECLARED for the system headers) and by no means fixes the support to 2byte chars. > > The patch is specifically thought for cygwin as I don't know whether > > there are other platforms (apart mingw) where sizeof(wchar_t) is 2. > > IIRC some (older?) commercial unices have this too. So maybe the --with-stlport-hack switch makes sense. > > If you think that it can be more generally useful, I can modify the > > patch such as to add a --with-stlport-hack switch to configure in order > > to enable the defines in the compiler invocation (he who builds LyX > > should then use a patched STLPort library). > > > > I would like to apply the stlport-hack.diff patch (or a modified version > > of it, if you agree on adding the --with-stlport-hack switch), so please > > tell me if there are any objections. > > It does not make sense, as I explained above. Why don't you add the missing > specializations to the LyX sources? The runtime crashes will tell you what > is missing, and if you for now just add stub functions that do assert for > the latin1 subset of ucs4, then they can be implemented easily, and you > have at least something that works in many cases. If you want to implement > true ucs4 support then you have to get your hands dirty with unciode > stuff, I don't see any other way. Unfortunately I am not able to build LyX with debugging symbols. The thing is pretty big and the final link stage fails with the error "Memory exhausted" when I use -g. I only have 256 Mb RAM in this old laptop. I have yet to be convinced that it does not work. Please, can you think of some test that I can perform? -- Enrico
