[Libreoffice] building index at Win32 install time ...

[Tor Lillqvist]

> On Windows why can it not use the native STL available there? 

I think it is because of compatibility with existing binary extensions written in C++ that are using stlport, so LibreOffice itself must keep using it so that its libraries are compatible with such extensions. So when we can declare an ABI break, yeah, then we can stop using stlport on Windows.

(Somebody please correct me if I have understood wrong.)

Why did they start using stlport on Windows in the first place, I don't know, but I can guess that Microsoft's STL was too broken back in the days when OOo was built using MSVC .NET (2003), or even earlier. And apparently extensions built at that time are still supposed to work. (Hmm, hopefully such binary extensions built with an ancient compiler come with their own copy of the (compiler version -specific) C/C++ runtime, because we ship only that which LibreOffice itself needs. Or we should, I think in 3.3 we still ship msvcr71.dll for Java's jvm.dll's sake, even if we shouldn't.)

> Is it because you need to be able to build with non-MS compilers which don't
> come with appropriate redistributable libraries?

Not really; C++ code compiled with different compilers is not binary compatible anyway. I guess the only other compiler that is relevant on Windows for us would be gcc (i.e. "MinGW"), and if/when we eventually manage to start building LibreOffice with gcc (in a cross-compiling manner, for sure), we will break ABI anyway.

> Anyway, here's what it links to on Linux (Ubuntu 10.10):
> $ ldd idxdict

Unfortunately not really useful as on Linux, STL is part of the normal libstdc, isn't it, so one doesn't really see if it imports also STL stuff from it, or just other C++ library. 

But anyway, I should just have checked myself, looking at the imports of idxdict .exe shows that it indeed does import quite much from stlport_vc7145.dll.

(Yeah, the name for the stlport DLL is heavily misleading, there is no VC71 involved in building a current OOo/LO version... But that name can't be changed without breaking existing binary extensions.)

--tml