...as for the by-default --enable-qt5 case we generate an additional
qt_soffice.html anyway (and for a --disable-gui --disable-qt5 build, client code
probably wants to embed the results into its own HTML document and wouldn't rely
on an soffice.html); this simplifies the build infrastructure a little
Change-Id: Ib50799b5dd2fcfeb680f257f46ff65775dcddd71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174725
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
What I'm after in the context of our Embind-related code is the claim at
<https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html#memory-management>:
"JavaScript only gained support for finalizers in ECMAScript 2021, or ECMA-262
Edition 12. The new API is called FinalizationRegistry and it still does not
offer any guarantees that the provided finalization callback will be called.
Embind uses this for cleanup if available, but only for smart pointers, and only
as a last resort." However, with the recommended emsdk 2.0.31 my tests did not
show any use of that finalization support. So I wanted to try with the latest
emsdk 3.1.51 instead. But then, linking vcldemo failed with
> wasm-ld: error: ~/allotropia-qt5/lib/libQt5Core.a(qlogging.o): undefined symbol: std::__2::__vector_base_common<true>::__throw_length_error() const
etc., so I gave it a try to rather build against latest Qt6.7, with
> --with-distro=LibreOfficeWASM32
> --disable-qt5
> --enable-qt6
> QT6DIR=...
TODO: The result is highly experimental, and it uses ENABLE_QT5 (i.e., the
recommended setup with emsdk 2.0.31 and the
<https://github.com/allotropia/qt5.git> v5.15.2+wasm branch) vs. ENABLE_QT6
(i.e., my experimental setup with emsdk 3.1.51 and the
<https://github.com/qt/qt5.git> 6.7 branch) not only to distinguish between Qt5-
vs. Qt6-specific behavior, but also to distinguish between old- vs.
new-Emscripten-specific behavior. Of note:
* The startup code appears to have changed substantially (and required setting
-s MODULARIZE=1 and -s EXPORT_NAME=soffice_entry now, and telling emcc to
build just soffice.js and not the wrapper soffice.html. TODO: This also
required hacking into qt_soffice.html: (1) The command-line arguments
(--norestore, --nologo, --writer, and the exammple.odt; all of which we should
eventually get rid of, anyway). (2) Saving the generated instance as
window.Module (and adapting the embindmaker-generated code, cf. the changes to
static/README.wasm.md).
* There were some symbol clashes between external/argon2 and
libQt6Core.a(qcryptographichash.cpp.o, so renamed the problematic symbols in
external/argon2.
Change-Id: I5420ab566d560b11954ac6613249bfc53d8acb31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162695
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.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>
I was wondering why removing instdir stuff forced a rebuild of
the cross toolset. Turned out some cross-toolset bits were wrongly
depending on host build stuff. It even had FIXME...
As a consequence, gb_CPPU_ENV was replaced by config_host.mk flags
to provide an CPPU_ENV_FOR_BUILD and also uses the correct
OS_FOR_BUILD.
Change-Id: I50e8e8dca50ab1ad3164948a585a792a52e4a39a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116359
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.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>
We cannot silently convert user data or their used file formats
and then await them to accept it or reinstall an older version.
Let us make a soft change instead of an hard (heart) break
and avoid us to been attacked with fire and forks from our users.
This reverts commit 8d381ae8d6.
Change-Id: Ia153640935e355771acb85cf652f8fe4c21fafbb
Reviewed-on: https://gerrit.libreoffice.org/52731
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Only libraries (and similar for executables) built as Library need to be
registered; those built via ExternalProject are delivered by Project and
used via gb_LinkTarget_add_libs. This also means there is no need to
mangle the names in RepositoryFixes.mk.
Change-Id: Ib0b67f54e2eb6efdb0c454c9e2dd599ada229676
Reviewed-on: https://gerrit.libreoffice.org/6533
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
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
... instead of the import lib. If the DLL is an auxtarget, it cannot
be deleted without annoying errors, and we want to be able to rm -r
$(INSTIDR) and build incrementally from there.
- replace DLLTARGET -> ILIBTARGET
- replace gb_Library_DLLFILENAMES -> gb_Library_FILENAMES
- replace gb_Library_FILENAMES -> gb_Library_ILIBFILENAMES
- replace gb_Library_get_dllname -> gb_Library_get_filename
- replace gb_Library_get_filename -> gb_Library_get_ilibfilename
- replace gb_CppunitTest_get_libfilename -> gb_CppunitTest_get_ilibfilename
- replace gb_LinkTarget_set_dlltarget -> gb_LinkTarget_set_ilibtarget
Change-Id: I92a2f061a653b9b5941f3232d729987b1317b6f8
It would not be necessary to mangle the
affine_uno_uno/log_uno_uno/unsafe_uno_uno library names in
RepositoryFixes.mk if they were simply named right in the first place.
Change-Id: I0fce919549764d2335c5501c1110878b8709fa09
Those .jnilibs that are not needed as .dylibs (this includes those that are also
UNO components) are handled via RepositoryFixes.mk. The remaining one,
libjava_uno.jnilib is packaged as a symlink in instdir. Everything else is not
necessary and removed (including the venerable oddity macosx-create-bundle).
Change-Id: I34a1801b0733cdff885c1c72db16fa631c5d82ef
...confusion galore, but hopefully brings us one step closer towards a working
instdir for Mac OS X.
Change-Id: Icb37a4adb1f91c9e81aaf11036c9d3e548c5ba76
Add patches and/or tweaks to the following modules:
curl, cppunit, icu, lcms2, libxml2, libxslt, libxmlsec,
lpsolve, nss, openssl, python3
lcms2 has an inconsistency where the .lib and the .dll don't agree on
the .dll name.
openssl gets a honorable mention because apparently it's undocumented
custom build system can build with /MDd if one picks the right
configuration but i couldn't figure out how to do that in an hour of
trying, and just patched the release config instead.
Change-Id: I7854a0fc85247e398d561b4f513d09fe2d1ebb3c
Moved portions from module i18npool, all of former i18nisolang1 library
that now is i18nlangtag. Included are languagetag, isolang and mslangid.
This i18nlangtag code is now even used by module comphelper, so
disentangling i18npool and making this an own module was needed to not
create circular module dependencies.
Change-Id: Ib887c3d6dde667403fd22d382310ba5f1a9b0015
add a new gb_LinkTarget_use_system_win32_libs to abstract different
linker options on MSVC and GCC.
Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
add a new gb_LinkTarget_use_system_win32_libs to abstract different
linker options on MSVC and GCC.
Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
Stephan Bergmann