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

> 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