Age | Commit message (Collapse) | Author |
|
...by setting the LC_VERSION_MIN_MACOSX load command's sdk value to n/a in the
soffice executable.
See <https://bugs.documentfoundation.org/show_bug.cgi?id=122218#c167> for how
this helps, even though I have no idea why it helps.
(Adding that -platform_version linker option appears to generate warnings like
> ld: warning: passed two min versions (10.13.0, 10.13) for platform macOS. Using 10.13.
but which are probably harmless.)
(cherry picked from commit 645fe53be0dc36535dba0ed684e21ca4cda80d70)
Plus cherry-pick of follow-up b7fd89100d8653dc73955780358fe31d38b68ebf
"tdf#122218: Baseline Xcode 9.3 ld presumably doesn't support -platform_version"
(and resolving the merge conflict in desktop/Executable_soffice_bin.mk).
Change-Id: I043498c7ff2d148d4a7e1e0e9d46241b638f2eba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88667
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88753
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Pass file description in optional second argument to
gb_Executable_add_default_nativeres.
Remove duplicating version resources from officeloader.rc and launcher.rc.
Change-Id: I55c4fc85c470c3dd6f03d909a39459839e70b9cd
Reviewed-on: https://gerrit.libreoffice.org/78333
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
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>
|
|
Uwinapi is discontinued.
Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01
Reviewed-on: https://gerrit.libreoffice.org/23198
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
...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
|
|
Change-Id: Ibb0970cfde65b331a4b870cc254b0a6481889edf
|
|
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
|
|
If the link targets are not in workdir then 2 different aspects are
needed: the previously used location relative to workdir's LinkTarget
dir (for all the misc. related targets), and the full target file.
Adding an additional parameter to all LinkTarget functions would be
quite annoying, especially since it would need passing through all the
gb_LinkTarget__use functions in RepositoryExternal.mk; instead encode
both into the linktarget itself, and modify the functions
gb_LinkTarget_get_target to return the target and all others to return
the workdir linktargetname.
- replace gb_Library_get_linktargetname with either:
* gb_Library__get_workdir_linktargetname
* gb_Library__get_linktarget_target
* gb_Library_get_linktarget
- similar for gb_Executable_get_linktargetname
- similar for gb_StaticLibrary_get_linktargetname
- similar for gb_CppunitTest__get_linktargetname
- add calls to gb_LinkTarget__get_workdir_linktargetname where needed
Change-Id: I917ad7957fee50ec2517a9f9cc9ff452c8d97d1b
|
|
Change-Id: Ice900801109efc8591b9a3fb5c490d070b23730a
|
|
|
|
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
|
|
... new gb_LinkTarget_add_standard_system_libs
Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
|
|
Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
|
|
Okay, I give up. This obviously still does not work on Windows, but it
does on MinGW when I try to simulate it.
Change-Id: I9f2d7114df0498d5cc3a71431aacc7e49a5a78fd
|
|
Change-Id: I72b41e4826b7e93b5c8aeacbf6d9d52e3780f090
|