Otherwise I get compilations errors for PopupMenu, at least for
--with-distro=CODAWindows.
Change-Id: I5a3af1b04ab373527d26ab84bf3634568cfec1f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197870
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
The new Collabora Office passes the installation path as UTF-8. On
Windows, turn that it into UTF-16 and use the wide character APIs, as
one should.
Add some comments to LibreOffiecKit mentioning this.
Also make lok_dlerror() use wide character APIs on Windows, and return
the message as UTF-8.
The wrappers used for this UTF-8/UTF-16 dance are copies of those in
<tools/UnixWrappers.h> (but with different names), because sadly
including that file in LibreOfficeKitInit.h caused other complicated
problems because LibreOfficeKit is apparently seen as part of the UNO
API when the ODK is constructed.
(It would be *wrong* and unhelpful to try to use system codepage for
pathnames instead of UTF-8. Codepages are obsolete. A proper Windows
program should use the wide character APIs. The Windows file system
has names in UTF-16. Using system codepage will not work for pathnames
that can't be expressed in the system codepage. Such user profile
directories might very well exist on some machines.)
The "normal" parts of core of course already use UTF-16 all over the
place on all platforms with OUString, so core on Windows hopefully
already accesses the file system only using wide character APIs.
Also remove extendUnoPath(). There is no URE/bin folder in a core
instdir any more. (Otherwise, the code in it would have had to be
changed to use wide character system APIs, too.)
Note that this commit by itself is not enough to fix problems when the
new Collabora Office is installed in a location with a non-ASCII
pathname. There are more problems in fontconfig, freetype, and cairo,
most likely. But for other LibreOfficeKit use cases on Windows, where
core is built in a normal manner without the "headless" backend, this
might be enough.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I2458ed98b89abcd18bf6ad658e285fcc55fd28b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196401
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197542
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Jenkins
Otherwise we won't find the .pc files. Tested by running configury on
arm64 Ubuntu, for cross-compiling to amd64 Ubuntu. Note: No idea yet
whether such a cross-build will run successfully to completion, or the
result work.
Change-Id: I517c1674d1230f91341b240f02b1b65d3ceaaef2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197207
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Otherwise you will get linking errors if core is configured with that
option.
Change-Id: Id0982fb7f15f7d185b5fe4eaa15e905464d435f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197508
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Jenkins
This was much more complicated than expected. Most of that thanks to
the inscrutability of fontconfig.
Fonts from the Microsoft Store get installed in a separate folder per
product, under the WindowsApps folder. Each such font product folder
contains one or several TrueType font files, and metadata files, and
preview images, etc.
Add a C++ source file to fontconfig that uses DirectWrite to enumerate
the available fonts. Take only those with a source type of
DWRITE_FONT_SOURCE_TYPE_APPX_PACKAGE into account. Other fonts are
found as before, looking in the system fonts folder (typically
C:\Windows\Fonts) and in the per-user fonts folder (typically
C:\Users\username\AppData\Local\Microsoft\Windows\Fonts).
This C++ code requires headers from the winrt tree in the Windows SDK,
so add that to SOLARINC.
Sadly, thanks to the way fontconfig works (scanning directories for
font files), I need to let it scan the folders of font products from
the Microsoft Store to find the font files, even if the DirectWrite
API would already give us the font file names directly. But I didn't
want to modify fontconfig too much, so oh well.
There was something weird in how fontconfig calculates the hash for
directory names to be used in its cache files. It ended up creating
more and more cache files for the same directories each time CODA-W
was run. I could not understand what was going on, but in any case,
just making sure that FcConfigMapFontPath() and FcConfigMapSalt()
don't do anything on Windows seems to help.
Also change the way freetype is built so that only the special
FT_Done_MM_Var is exported, not all public functions. This was
necessary because for some unknown reason, when linking the vcl DLL I
started getting errors for the freetype symbols that happen to be
linked into also the cairo DLL. If we eventually can switch to
building all of core statically for CODA-W this problem will go away.
Also stop defining FT_DEBUG_LOGGING, such logging will not show up
anywhere for end-users, and fixing problems in freetype on Windows
will have to be done by reproducing and debugging in the VS debugger
anyway.
There is still much to do to make fontconfig (and probably freetype
and cairo) work really correctly on Windows. The most obvious thing is
that the file name handling is broken. This is perhaps understandable
as the port of that code to Windows is from over 20 years ago, I
think.
It works for file and folder names in ASCII, but most likely not for
others. At least the user profile directory, under which per-user font
files are stored, will definitely have non-ASCII in many cases. We
should modify the code to use <tools/UnixWrappers.h>, so that all file
system access is done using proper wide character (UTF-16)
APIs. Pathnames that these libraries handle will then be in UTF-8. The
opendir() etc emulation in fontconfig should also be replaced by
adding such to UnixWrappers.h instead.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I4bc6e32dcc32ff74b79679edacee1aecebd774c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196336
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Tor Lillqvist <tml@iki.fi>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197507
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
For instance, having both 10-no-antialias.conf and
10-yes-antialias.conf in the same conf.d folder is silly.
Look at what Ubuntu has in /etc/fonts/conf.d and keep only those. Note
that ExternalPackage_fontconfig_data is used only for WASM and CODA-W
anyway, so the "local" and "user" ones are surely irrelevant.
Change-Id: I76219eb38675f2e3018d84ab1fc845b1131cc4f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194613
Reviewed-by: Thorsten Behrens <thorsten.behrens@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197501
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Jenkins
Apps using LibreOfficeKit often have unusual lifecycles.
Change-Id: Ie113d7458cff10beba2e44181d0b6ce5758a7634
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197504
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
They have family names starting with a period. They are not intended
to be used by apps, and not normally visible in apps that use just
Apple APIs. So we should not use them even if they are found by
fontconfig. (Letting them be found leads to an assertion failure in
boost, even. Did not investigate further.)
See for instance
https://eclecticlight.co/2015/11/10/qa-how-to-use-san-francisco-font-in-docs/
, from which I quote:
👉 This is accomplished by prefacing its name and ID with a period
(.), so that its TrueType Unique ID record, for example, describes it
as “.SF NS Text”, and it is explicitly identified as a System Font.
This ensures that it is omitted from font selection menus and
dialogs. 👈
Change-Id: I4efea606331c5c37a321b30e908a0c8c789816e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195230
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197506
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Lots of things will have to be tweaked to build core statically for
Windows. This is just one small isolated and fairly obvious trivial
commit. (Assuming that in the disable-dynloading case, for Windows we
want to drop the same dynamic library loading functions in osl as for
Unixish systems.)
Change-Id: Ica0a00d7a3d5b85e5eb933ebd5722824fbf5deeb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197503
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
On a Mac volume mounted in a Linux virtual machine under Parallels
Desktop, hard-linking works (from the Linux VM). Looking at it in the
host macOS the linked files also show up as linked, with identical
inode number and a link count of 2. But in the Linux VM, the
hard-linked files each have a link count of 1, and different inode
numbers. (Still, they *are* the same file. If you write to one, it
shows up in the other, too, etc.)
I am not saying it necessarily makes sense to build core on such a
file system. Quite likely it makes more sense to just create a native
Linux file system on a Parallels virtual hard drive (that is a file on
a Mac volume). But it is fun to experiment with stuff like this.
Yes, if it turns out that we need to get the name of the file system
type some folder or file is on in other places, too, the code for that
should be put in some shared place.
Change-Id: I315eb2ed0fd0803da3070645119b2bd3019cc9a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197305
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
For Windows we build freetype as a static library. But we must build
freetype with DLL_EXPORT defined so that symbols like FT_Done_MM_Var
get exported by the DLL into which the static freetype library is
linked. That is mergedlo.dll or vcllo.dll.
Then in vcl's dlFT_Done_MM_Var() we can't just call
osl_getAsciiFunctionSymbol() with a nullptr for the first "module"
parameter and expect it to look through all modules, like dlsym() does
on Unixes. On Windows, osl_getAsciiFunctionSymbol() calls
GetProcAddress(), and passing a NULL first parameter to tht is simply
invalid. We must look for FT_Done_MM_Var in mergedlo.dll, or if that
isn't loaded, vcllo.dll.
Possibly it would be simpler to just pretend we don't HAVE_DLAPI in
this case and call FT_Done_MM_Var() directly.
Without this commit, FT_Done_MM_Var will not be found, so the code
will just call free() instead of FT_Done_MM_Var(), and if built using
the debugging C library that will lead to a strange assertion failure
in the C library. With the non-debugging C library it might perhaps
lead to some odd bug, or just not do whatever proper deallocation of
resources or something it is that FT_Done_MM_Var() does.
Change-Id: Ia7b726cc7167ba22ea8f3263ad85f8cd4ac5c483
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194608
Reviewed-by: Thorsten Behrens <thorsten.behrens@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197213
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Especially on Windows it is important to not call free() in your own
code on a pointer returned from some random other dynamic library
(like the one the desktop/source/lib/init.cxx code goes into). It
might have been allocated by calling malloc() (etc) in a C runtime
library that is different from the one used by your code. That will
lead to a crash.
One should alays call the free() in the same C runtime where the
malloc() that allocated the pointer is.
Add a wrapper called freeMemory() to the C++ API.
Change-Id: Ibf9cf6fad2c30c4416d2a1f6badbd161c7ba18a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194594
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197107
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Can easily happen at least on WSL.
Also avoid warnings about the deprecated readdir_r(). In current
POSIX, readdir() is required to be thread-safe. (It might well have
been for a long time in those POSIXish platforms we care for, I don't
know.)
Change-Id: I2b89b7aa170f661365580979d151c1b0557955fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197053
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
No need to look up a cairo function dynamically as we know that in
Windows we are using a cairo we build ourselves so we can be sure that
it is has what we want.
There is a TEXT() macro in winnt.h, and we use that (indirectly)
elsewhere, so we can't just undefine it in postwin.h. Thus we can't
initialise a variable calld TEXT using parentheses.
Check USE_HEADLESS_CODE before checking _WIN32 to get the former code
in the CODA-W case and the latter otherwise for Windows.
Change-Id: I8987e3b33d51ea232f8262413d17a50910d8e7b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197007
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Note that this patch is for now just a start of work that is paused
for now. The handling of non-ASCII filenames in the external libraries
that in the CODA case are now used also on Windows is likely very
broken, and needs to be carefully checked and modified. The new
<tools/UnixWrappers.h> thing, with additional work, will probably be
used.
Change-Id: I30cb09747a8de8716608669a75c872b73812b3f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194587
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196986
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Jenkins
We variously look at both ENABLE_HEADLESS and USE_HEADLESS_CODE to
check for the --enable-headless case. Are both really needed?
In the --enable-headless case, freetype, fontconfig and cairo are
built. For now, cairo is built as a Library (DLL), but fontconfig and
freetype as StaticLibrary. Possibly should change these to DLLs,
too. (See preceding commits.) Do not build the vclplug_win.
Windows-specific fixes to the headless vcl code, and headless-specific
fixes to some Win32 vcl code. Use <tools/UnixWrappers.h> where
appropriate instead of <unistd.h>, <sys/mman.h>, etc.
fontconfig already has code for Windows, but likely things will break
on machines with a non-ASCII name for the Windows fonts directory, or
for funky font names. Should eventually make it use the new
<tools/UnixWrappers.h>.
Change-Id: Id3a1313083b1c7c44b0b26819c1ffb5138e15bc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194573
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196980
Tested-by: Tor Lillqvist <tml@iki.fi>
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Notes for the master branch:
* "CODA" was (is) the internal codename for what now is known as (the
new) Collabora Office. It stands for "Collabora Online as a Desktop
Application".
* This indeed was just the initial attempt, the file will be modified
in later commits.
Change-Id: I6c0d97998b5e57b6738086f8460bb9d0c1491d08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194555
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196627
Tested-by: Jenkins
We don't use it yet from any C source file, but the plan is to do
that. Mainly from freetype, fontconfig, and cairo, when these are
built for Windows when the --enable-headless options is used (for the
new Collabora Office).
Also some cleanups, sorting #include lines, avoiding warnings, etc.
Change-Id: Ifef3588d06fdcceaeaeb3482399737faaf558d7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195602
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Of course, LibreOffice has tons of APIs from before whose whole point
is to hide system dependencies behind a cross-platform API. All the
"sal" and "osl" stuff, for starters. The wrappers in this file is not
intended to replace those. The point with these wrappers is to quickly
port code that was written for Unix *only* to Windows, with minimal
changes to the source code. Basically you just need to prefix calls to
functions like open() and stat() with wrap_.
In Windows, "file descriptors" are a thing in the C library, not the
operating system. But the C library does provide the same core set of
functionality as Unix-like systems do. The functions use almost the
same names, except that for some reason, to avoid compilation
warnings, you need to call variants with names preceded by an
underscore, like _close().
Another Windows complication is that the file system is based on
UTF-16 names. You can't just pass file names as eight-bit characters
to _open() and expect it to work for all file names. Instead, you need
to call a function with a "w" prefix, like _wopen(), that takes a wide
character string (UTF-16).
This header is in C, not C++, because we want it to be usable from
some external libraries written in C that we compile as part of
LibreOffice in some circumstances, particularly for Windows.
All functions behave like the wrapped ones, set errno on errors.
Change-Id: Ia093ccf976659ceabbef6e0071da73d4df0b63b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195422
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Look for the mangled ++ name, to catch a potential mismatch in
function signature. Also, check that the returned function pointer is
non-null before calling it.
Change-Id: Ib2e0d1cd4b3e26081800b736b74e5972d0819736
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195380
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The PDF export functionality displays a dialog from JavaScript that
allows the user to choose various PDF parameters. But unlike export to
other formats, no system file save dialog gets displayed by CODA. So
do something horrible: Look up a function in CODA.cpp and call it
directly. Sorry.
Change-Id: I21932b2ba67d3aab72463d51f8ef71182ca5c736
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195379
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Alternatively we could just remove lots of stuff that we apparently
don't actually need from this file, including the problematic typedef
and its uses.
_Unwind_Exception_Class now gets typedeffed in <unwind_itanium.h> as
uint64_t which effectively is the same as the unsigned
__attribute__((__mode__(__DI__))) that is used here.
Change-Id: Id96d43eb481ee4ae97dd315aa2fd741e5f627916
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150702
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
If the inpt matches one of the constants exactly, the result is the
name of that constant. If the input matches some combination of
constant values that are single bits, the result is the sequence of
the names of those constants joined with plus signs.
For instance, if the IDL has:
constants Constants {
const byte BIT0 = 1;
const byte BIT1 = 2;
const byte BIT2 = 4;
const byte BIT3 = 8;
}
The result of Constants::to_string(5) is "BIT0+BIT2", and the result
of Constants::to_string(17) is "17".
I am sure there are corner cases that aren't handled as would be
intuitive, especially with types that include unsigned values.
Correspondingly, the semantics of the generated to_string() functions
is not formally defined.
Also add a unit test for the new functionality.
Change-Id: I14aa826d0989ac6dfe97dd5c09119b1601c65643
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148995
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
It turns out that Mert's original idea is actually the simplest and it
is known to work. And in that, the separate paintThumbnail() is rather
pointless, as all paintThumbnail() did was to call paintTile(). The
caller (in Collabora Online) knows when a file is opened specifically
for thumbnailing, and can call paintTile() itself with the appropriate
parameters.
My misguided idea would have had paintThumbnail() somehow figure out
the physical Twip coordinates of the current location (for text
documents, the insertion caret location) in the document. (Or, as
LibreOfficeKit for some reason calls them, "logical" coordinates, even
if a Twip is a very physical length unit.) Then it would have called
paintTile() with those coordinates. But it turned out to be rather
hard to figure out the Twip coordinates of the current location in
the document.
Mert's idea was that when a document is opened for thumbnailing, only
Online actually needs to know that. From LibreOfficeKit's and core's
point of view it is a normal document load operation. Then Online
performs the .uno:OpenHyperlink magic, which makes core move the
current position to the requested "target" or "mark" (the terminology
varies) location. And then a "cursor" callback is used by Online to
get the Twip coordinates of the target. It is a bit unclear to me
whether .uno:HyperLink causes the document to be opened an extra time,
but whatever, this way is said to work. So let's do it like that.
This reverts the paintThumbnail part of
1aa37ca991.
Change-Id: I8f3d9917ee362c1518834fc10a57c57ebc4a6edb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148390
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Instead, have a function that returns a reference to a local static
variable. That local static is then initialised only when the function
is called for the first time. Calling CuiResId() in a global
initialiser is a bit questionable, and causes an uncaught exception
when LO core is used in a WASM app. Possibly it would also have been
problematic on other uncommon platforms.
Change-Id: I4fd799ba3aa8d63fd3db1eb8cf6211aeed904ed2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147512
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Emscripten and WASM do have some support for SSSE3, so let's try to
use it, with -msimd128. See
https://emscripten.org/docs/porting/simd.html.
WASM is not x86, though, so avoid use of inline x86 assembly, like the
CPUID instruction.
Emscripten does not have <mmintrin.h> but does have <xmmintrin.h>,
<emmintrin.h>, and <tmmintrin.h>.
Change-Id: Ic3a47291f6c6dee6843e93ccecc92a643b269cb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146691
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
We want that only the ForKit process needs to have access to new font
files added to a Collabora Online instance dynamically by downloading
from a server. There are however many locations in the Kit process, in
core and in external libraries like harfbuzz, where the code wants to
open a font file.
Handle this so that the ForKit process opens such a downloaded font
file and doesn't close it. The file descriptor is thus inherited by
Kit processes. The font file pathname passed on to other code is a
fake on in the format "/:FD:/%d" where the %d is the file descriptor
of the opened font file. Add checks in all places where font files are
opened, look for this special pathname format, and modify the code to
just dup() the already open file descriptor in that case.
All this is relevant for Linux only, as Collabora Online runs on
Linux.
Do the above for harfbuzz, cairo, fontconfig, and freetype.
In addition make sure that these libraries (except harfbuzz which
needs to be a static library and freetype) when bundled, on Linux, are
built as shared libraries, and won't be confused with the
corresponding system libraries by making sure their sonames are
different.
Change-Id: Ib059cb27e1637d07bb709249abd0d984f948caa9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140714
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146341
Tested-by: Jenkins
After 7a6324ea0d I started getting UNO
exceptions with the message "component context fails to supply service
com.sun.star.xml.crypto.SEInitializer of type
com.sun.star.xml.crypto.XSEInitializer".
It is likely that it breaks in the iOS and Android apps, too, so
bypass for those, too.
Change-Id: Id08afbf6bea071c8b0b6564342716e0b064cb712
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146071
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
The Emscripten compiler, emcc is a Python script that wraps the actual
compiler. It outputs annoying warnings like
.../emscripten/tools/building.py:638: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/emscripten_temp_0fvvg__1/conftest.js.jso.js' mode='w' encoding='utf-8'>
to stderr. (Ditto for em++.) Some steps in typical configure script
think that a non-empty stderr means there was a problem in compiling a
test program. This happens even for a microscopic test program with an
option like -Werror which surely *is* supported. Avoid this by
setting PYTHONWARNINGS=ignore.
Change-Id: I11927fc7dccaa65a239ba65dfc7c6bb7487bf12d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146070
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Only check whether LIBO_INTERNAL_ONLY is defined or not. Don't check its value.
If undefined, its value will default to 0, but checking the value will
cause a warning that will be treated as an error if you compile with
-Werror, as you should.
Change-Id: I1d9e4569a016d2e6dbaa9d612071a5528ff1902e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146066
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Earlier, no -O flag at all got used in the cairo and pixman
builds. Which was sad, as these two libraries are performance-critical.
Yes, this change is quick-and-dirty. The proper way would be to modify
things in solenv/gbuild. But that is somewhat complicated.
In general it seems fairly hard to make sure the same compiler flags
get used for every external bundled library. Each external library is
a special snowflake, more or less, with a differently structured
ExternalProject makefile.
For instance for the libwpd library (just picked randomly as an
example), even -O2 gets used. (Which as such is OK.) This despite
solenv/gbuild/platform/EMSCRIPTEN_INTEL_GCC.mk apparently trying to
enforce use of -O1 for Emscripten.
This change has a visible impact on the performance of COWASM.
Change-Id: I99d74db2da733134fde16661881856f9a81100f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146009
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Actually, it seems that to build core with --fwasm-exceptions for use
in a LibreOffice Technology -using WASM executable, you need to
compile *everything* with that (i.e. *all* of core's externals). Just
these gbuild things are not enough to ensure that. You have to put
CC=emcc -pthread -fwasm-exceptions -s SUPPORT_LONGJMP=wasm
CXX=em++ -pthread -fwasm-exceptions -s SUPPORT_LONGJMP=wasm
into your autogen.input.
Change-Id: I10d21ad0f73e7e5d72864864d595077bd770f4f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145646
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
It causes a problem when building with Emscripten and
--enable-wasm-exceptions. Instead of fixing that problem, just don't
bother building executables we won't run anyway. (Ideally liborcus
should have some --disable-benchmark configure options, ping Kohei.)
Change-Id: Ic8c1d51513793bba85dc2833cc8fd9ec5b97ce76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145645
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tor Lillqvist