Change-Id: I0cbe7b4c6d329f2780cb3cac9bce6d722b7de469

Change-Id: I8d8dd139e57fb00decda8705157480439009cde8

Change-Id: I6767c62265dcfbb55ce086385802db59d4d0b177

Change-Id: I411133e81a9b548aaef2333c705c1376f45304d7
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/1294Reviewed-by: Luboš Luňák <l.lunak@suse.cz>
Tested-by: Luboš Luňák <l.lunak@suse.cz>

Change-Id: I4912ffc42edbfa1456835e61163812c371eb14c6
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com
Reviewed-on: https://gerrit.libreoffice.org/1293Reviewed-by: Luboš Luňák <l.lunak@suse.cz>
Tested-by: Luboš Luňák <l.lunak@suse.cz>

- removed rtl:: prefix
- removed RTL_CONSTASCII_USTRINGPARAM
- corrected some misspells

Change-Id: I88bb0beec718a7fe38c61220aa61401419f23b42
Reviewed-on: https://gerrit.libreoffice.org/1291Reviewed-by: Luboš Luňák <l.lunak@suse.cz>
Tested-by: Luboš Luňák <l.lunak@suse.cz>

Initializing the liblangtag database stuff takes much percentage of
startup time, avoid that.

Change-Id: Ieb12ff71c2b1421a5644acebaef4c8366694c249

For "simple" known (to us) locales avoid the overhead of liblangtag,
also in preparation of not having to initialize its database during
startup.

This also enables recognition of the 'qtz' pseudolocale for key ID
resources again, see fdo#57413

Change-Id: Id52a1ddc37b42063e3bf68a6dbeaeacfbfa704ef

and apple gcc-4.0.1 chokes on this

Change-Id: I4799d66f483f10d9b633077a16d25208c8b595e0

Change-Id: I861c49d2b0dfc57d6e777b14742cb324e4d4d0a8

Change-Id: I120acd40b83cad074869b404d4e74b5ec69d493d

Change-Id: I9d31602750dc6516b7bee5c0796328cee07b10ea

Change-Id: Iffa3296a15cbfaef8b7eca0648d9d954c92b3d4a

Change-Id: Ie8a2c7e473d717cc22c51205dd8cdc59934de8b1

Change-Id: I23b6b8fdbb9c4f367a590a21e40e7bbaa76f7fce

With MSVC2010 compile time goes 20 minutes -> 7 minutes. With Clang
it's however 7 minutes -> 10 minutes, apparently the overhead
caused by all the extra data is bigger than the gain.

Otherwise gb_CppunitTest_use_library_objects won't work with MSVC.

Rather than LinkTarget/external_headers, as this doesn't really make
any difference, except if PCH is made to also use headers from the same
target (not a very good idea for development, but might be useful
e.g. for buildbots).

Change-Id: I9041129289c24c4ee8a7a6d50e34b785969e8204

Change-Id: I6eb52f42c3364970553015492b9c488c04febed6
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>

This is to complement the RTL_FAST_STRING variant, which allows any
combination, so even two stringbuffers.

Change-Id: Ic15d81246b3d0f3e22b51c0516409e95c3a4dc8d

Change-Id: I692a9cfdca5ad50170eea2178a6aa87e8154b951

This rather substantially accelerates the first use of autocorrection.
Interestingly, it also appears to accelerate the sorting of the items;
potentially inserting sorted items into a set is a pathological balancing
case, that is avoided by the hash algorithm's randomness.

... objects at the right page.  This was effectively disabled for all
anchor types except FLY_AT_PARA by a misplaced ! in the conditional,
and C++ not being a type safe language.

Change-Id: I64af2141e577ac896292eecd9f8c46c62a0548db

Change-Id: I097675450a0eed87eccf90356c81657485609d13

Specify subsystem version 5.01 in the linker options. Otherwise, when
built with the linker in Windows Kit 8.0, executables are created with
the "operating system version" and "subsystem version" fields set to
6.0 (which means Vista).

Attempting to run such executables on Windows XP fails with an error
that claims them to be "invalid Win32 executables" (which is a blatant
lie, of course).

We can well set the subsystem version to 5.01 as we don't
unconditionally use any APIs that wouldn't be present on XP.

Note that you need Visual Studio 2012 Update 1 to be able to create
code that runs on XP. The original version creates executables that
importx entries from kernel32.dll like GetTickCount64 that aren't
present on XP.

Apparently it doesn't hurt on XP that DLL headers specify a "too new"
subsystem version.

This reverts commit 21ea3725.  Looks like
neither XNotifyingDispatch nor XSynchronousDispatch can be used to avoid this
race; sigh.

Change-Id: Ide65bcf203f78d1e8d3286f4ee19846a357fb364

Change-Id: I6e9947f056c0b70d629ac27d57b3d7d115f8d487

Project: translations  85f724f5aa1d6a59662a7d1c7ea406a641814bd2
fdo#58068 fix invalid .po headers

Change-Id: Id151d59a9bab2454b9d359aefb5c35a9f05bb9ce

The very same libstdc++ that breaks with clang and -std=gnu++0x
has also the ABI breakage that prevents using C++11 anyway.
Moreover, there's still the idea that we should preferably use
the gnu variant, just like the default is -std=gnu++98, rather
than strict C++11 (the gcc manpage for -ansi e.g. says that
some builtins are disabled in this case).

Change-Id: I4dac01374ee7a34796161f6e0e76eb962953e709

Change-Id: Idca64b8925199f3d275e7966c1d0e13fee4967a8