...by implementing (for now) just enough of the cpp2uno half of the Wasm UNO
bridge to make it work. In general, that half suffers from the same issue as
the already-implemented uno2cpp half, namely that Wasm doesn't allow to generate
code on the fly (which, in this case, would be needed to implement the vtable
slot trampoline functions). So, for now just hard-code the few
vtableSlotFunction_* that are needed by the UNO interfaces for
cppuhelper/source/exc_thrower.cxx. (A proper fix would probably use the same
approach as for the uno2cpp half, and use something like wasmcallgen to generate
at least all the vtableSlotFunction_* needed for udkapi/offapi upfront.)
The RTTI for the exceptions needs to be unique across the executable for
exception catching to actually work (as it compares exception types by RTTI
address rather than by name). We thus need to export all the relevant RTTI
symbols (which I hacked into the existing wasmcallgen for now, even if that
makes that executable's name a slight misnomer now), and access them with a new
jsGetExportedSymbol. (This exporting would also be needed by the "classical"
approach of using dlsym on the main module, cf.
<https://gerrit.libreoffice.org/c/core/+/167187> "WIP: Emscripten: Set up
support for dlsym from main module". And while that dlsym approach would work,
it is much simpler to just use that jsGetExportedSymbol than to use a dlsym
detour, and thereby avoid all the hassle of -sMAIN_MODULE detailed in the commit
message of that Gerrit change.)
It also turned out that including Emscripten's <cxxabi.h> needs
__USING_WASM_EXCEPTIONS__ to be defined, because it uses that in its declaration
of __cxa_throw. (The source for setting that define internally in Emscripten is
get_cflags in the emsdk's upstream/emscripten/tools/system_libs.py, which
defines __USING_EMSCRIPTEN_EXCEPTIONS__ for the non-Wasm, Emscripten JS
exception mode, and defines __USING_WASM_EXCEPTIONS__ for
--enable-wasm-exceptions, which we use. The commit message of
f4ec967599 "Fix redefinion of Emscripten
__cxxabiv1::__cxa_exception" documents my prior confusion of when one or the
other would be defined.)
Change-Id: Id08765ab5b4ce1553dc3a61648324526185cb64c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170246
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Also, when building a .dmg for macOS, skip codesigning for non-release
builds, both with and without the macOS sandbox, if there is no identity
set but set entitlements to allow Xcode's Instruments application to
connect to the application.
Lastly, add entitlements when building soffice in $(INSTROOTBASE) if
this is a non-release build.
Change-Id: I764bf5bd5d44e878669c4287906e6efd6aac593f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152655
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
... resulting in a stripped-down, Writer-only build to decrease
the resulting WASM bytecode size.
It removes the following code from the build:
* All other major modules: Base, Calc, Chart, Draw, Impress and
Math and related writerperfect filters
* The premultiply tables
* The (auto-)recovery functionality
* All accessibility (but not the accessibility document checker)
* The LanguageGuess component
* EPUB support
* The start center / BackingWindow
* The TipOfTheDay functionality
* The splash screen communication
Currently crashs with anything different then soffice --writer.
Closing the document also still crashes.
FYI: many of these features are now behind ENABLE_WASM_STRIP_*
defines, but they normally don't work on their own, globally!
That's because we started with stripping the main components.
Change-Id: Ib9c0f9452815910c0a2aceaf142ba1ad4a9cb0d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126182
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
All the small stuff, which is needed for the WASM build, but is
not really worth an extra patch.
* No soffice.sh script needed for WASM
* WASM soffice.bin executable extension is html
* Some small additional SAL_LOG output
* Default to colibre icon theme
* Test for qt5 even without X11
* Remove emconfigure artefacts at the end of the configure run
* No oosplash for WASM
* Disable the Office IPC thread
* Suppress -Wno-enum-conversion for Cairo builds
* Fix libnumbertext by using gb_EMSCRIPTEN_CPPFLAGS
* Map EMSCRIPTEN to LINUX nls
* No extra newlines for missing icon theme images
* Print the missing dependency in some gbuild error messages
* Copy Qt WASM loader, HTML template and SVG logo for binaries
* Especially build the vcldemo for Emscripten
Change-Id: I356370c72cc09357411e14d0c00762152877a800
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128584
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This allows to build a complete static LibreOffice on Linux,
except for linked externals. Since LO's static build implies
disabled dynamic loading, one must select one VCL backend to
be compiled in.
See the (large) comment in solenv/gbuild/static.mk trying to
explain, why this implementation was chosen (spoiler: seems
there is no other way) and what is actually implemented.
This will collect all libraries, statics and externals of
executables. If the executable uses components, it will get
linked to all static components. While it works with any
Executable, it just makes sense for soffice.bin, because the
static component map sucks every dependency in, bloating most
other binaries.
In theory on could generate the dependencies based on the list
of used components (see gb_CppunitTest_use_components), then
generate a specific static constructor map, directly include it
in the exe's cxx code and then link the minimal dependencies.
The static LO should build on Linux with:
--enable-customtarget-components
--disable-dynamic-loading
Tested VCL plugin config is:
--disable-gtk3
--disable-gen
--enable-qt5
The partial build support is split into a 2nd patch.
Change-Id: Iafc95752fae9e88095f54a21f1e30a4f080815e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126790
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Drop Build prefix and settle on Lib and Exe prefixes. Also add a
note about the "else" part of the condition and fix offenders.
While at it, define COND_LIB_SAL_TEXTENC to be used by sal to
prevent diverting coditions in build and cxx code.
Change-Id: I944587ca1ccbe46b765d1a631a7214c8126fe951
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128136
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Currently we don't destinguish between between extensions without
code, which couldn't be executed with DISABLE_DYNLOADING, and all
other extensions, like translations, dictionaries, etc., so there
is no need for a static unopkg.
Change-Id: I427a51b3174d074e467a582e808490a85e98e8eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128114
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This way we can get rid of the pre-generated locale data and the
special fuzzers target, which invokes a full gbuild make for
every prereqisite, always parsing the whole tree, taking ages.
This also reverts:
- commit d0780b21cf ("fix oss-fuzz
build") by adding epubgen and revenge dependencies.
- commit ff25d6a123 ("ofz#41602 fix
more build failure"), which shouldn't happen anymore since
commit d47628f287 ("don't want to
link to system static libs for DISABLE_DYNLOADING")
Change-Id: I3aed9ec62da507254b42e4e7470bae1097b4bc8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127031
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
In situations when no command line params are available (for
example in Windows Store msix packages they are still missing)
let's try to use another executable shortcut for soffice
Change-Id: I6d083912dbed1166d2d68efa5eb0096b73cb58c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98382
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Being a GUI application on Windows (with related flag in the executable header
- see https://blogs.msdn.microsoft.com/oldnewthing/20090101-00/?p=19643/), OS
would detect the subsystem before launching the application, and won't attach
the parent console or redirected output handles from it to the application.
Also, different hacks to reattach the GUI application to the console later are
unreliable on different Windows versions, and work improperly (the output goes
to the console after the launch command has already returned, which is wrong
in batch files). This makes it extremily difficult to do CLI operations with
LibreOffice on Windows, with error codes/warnings/messages/output missing or
going to wrong consoles.
Making an executable for CUI subsystem, on the other hand, makes Windows to
allocate a console before starting it when the program is run by itself. This
makes the console window to appear on screen unconditionally, even if it's
hidden later when the program has started. This flashing is undesirable.
But we use a wrapper executable on Windows, called soffice.exe, which is what
actually launched by user, and which runs soffice.bin. This allows us to make
soffice.bin the proper console application, and thus make it capable to behave
properly in CLI scenarios, while avoid the console flashing when run from the
soffice.exe (which would suppress the console creation using DETACHED_PROCESS
creation flag to CreateProcessW).
Also creating a new wrapper for console (soffice.com) allows to use command
lines which omit explicit executable extension (no ".bin"), like this:
"C:\Program Files\LibreOffice\program\soffice" --help
which allows to continue using multiple available help resources unchanged,
since .com extension is tried prior to .exe by Windows' cmd.exe.
Change-Id: I089d0f30f860da6cfc781b4383f6598a08a4d238
Reviewed-on: https://gerrit.libreoffice.org/63572
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This gets rid of the horrible hack in gbuild.mk to accomodate the
case-incorrect iOS platform makefiles that cannot be renamed without
upsetting git on file systems that sadly lack the case sensitivity
feature.
Keep the macro defined to IOS though.
Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234
Reviewed-on: https://gerrit.libreoffice.org/62705
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
since it has nothing to do with the headless command line option, so
use the name it has in the configure.ac file
Change-Id: Ibf0615ed02695d6e48a797f5632e4f417c010c70
Reviewed-on: https://gerrit.libreoffice.org/59611
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
Or could it be that some external scripts insist on running
LibreOffice.app/Contents/program/soffice? Or some instructions talk
about that pathname?
Change-Id: I99e2b2636971c7ee8de09a9e42df9f965eeec5fb
Up to now the screenshot creation was added/dependent of
target slowcheck. Since quite some modules have added screenshot
creations now, I added an own target 'screenshot' to allow to keep
current slowcheck and screenshot creation separated
Change-Id: I80a49a0db607edf8e0405672d570f624d29912e7
This patch adds support for Office URI Schemes (see
https://msdn.microsoft.com/en-us/library/dn906146).
This will enable browser (non-CMIS) integration of LibreOffice
with MS SharePoint server (v.2013 tested).
In this patch, in addition to ms-* schemes, a new scheme is
introduced: vnd.libreoffice.command, which is analogous to ms-*.
Its purpose is to enable flexible configuration of server and
client, where some types of documents are declared as handled by
LibreOffice, and other are handled by other software. E.g., ODTs
may have "vnd.libreoffice.command" scheme, while DOCXs could be
"ms-word". Client may register LibreOffice to handle both, or to
handle only "vnd.libreoffice.command" scheme.
Unit test included.
TODO in a later patch: add a mechanism to register LibreOffice
to the schemes with OS.
Change-Id: I1c449a211102036f87163058a4c90a93eb32c948
Reviewed-on: https://gerrit.libreoffice.org/27094
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
The plan for the near future is to still ship the executable but replace
the interal use if possible with using the static library.
At some point when it is not needed for debugging anymore and everything
works correctly we should only build the uploader executable in dev
configurations. The huge disadvantage of the interal solution is that it
is nearly impossible for a user to upload a crash report if LibO starts
working correctly. Also LibO overwrites the file with the information
after the upload whereas the executable does not.
Change-Id: Ib9854946be3a34e580964c18e1a9c0cce16221d1
Reviewed-on: https://gerrit.libreoffice.org/25862
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Since the test would fail to link on Windows, due to
ifeq ($(GUIBASE),unx)
$(eval $(call gb_Library_add_exception_objects,sofficeapp,\
desktop/source/lib/init \
))
endif
in Library_sofficeapp.mk. Given that
CppunitTest_libreofficekit_tiledrendering is marked as Linux-only as
well, be consistent and have this test as Linux-only, too.
Change-Id: I6c8884398eba5dcf8a74c9cdc96c869b6108fb7e
We needed a better way to test LOK methods that are not app specific,
but are defined in /desktop/source/lib/init.cxx. So the decalaration
needs to be visible.
I also moved the `getStyles` test in the new test file
Change-Id: I98d97dc17a66e72732ca7bd848c131610790f48e
...assuming the delayLoadHook in cli_ure/source/native/native_bootstrap.cxx is
no longer necessary and loading of cppuhelper from the program dir cannot fail
regardless in whatever scenario the cli_cppuhelper library itself is loaded.
Change-Id: I13f32b327bca4cce9780864f5e57cdad3860afe5
- this renames the 'almost' module target to non-l10n
- and adds a l10n target which is intended to only build l10n parts of
the product
- packagers should then be able to build l10n and non-l10n parts of the
product independently, thus:
- enable quicker rebuilds
- distribution of load
- updates to l10n without a full rebuild
- security fixes to binaries without rebuilding all l10n
- the new targets are called build-l10n-only and build-non-l10n-only
- note this is not intended to move a concept of split packages
upstream -- while this exsists in distros, the number of test
scenarios for this would explode upstream
Change-Id: Ib8ccc9bc52718d9b0ebbfee76ad93dc29c260863
Conflicts:
filter/Module_filter.mk
Clean up the horrible mess around unopkg.bin unopkg.com unopkg.exe and
soffice.bin soffice.exe and crashrep.com executables and associated
renaming via Packages in the desktop makefiles by simply using
RepositoryFixes to correct the names.
Change-Id: I4d3a549462cfa90a63d62b35db1b0407b25239f7
Caolán McNamara