...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
1. Avoid explicitly specifying COM_QUERY in calls to QueryInterface
(it is implied from the name).
2. Drop redundant ctor and set() that duplicate QueryInterface.
3. Allow ThrowIfFailed without a message.
Change-Id: I75b545e534efb7e57da131dfd40a2a49d204efac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198033
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Use IID_PPV_ARGS, to avoid dependence on specific implementations
of MS COM interfaces.
Before this, it relied on QueryInterface taking one argument, which
is a specific inline method implemented in <Unknwnbase.h>.
Change-Id: I1386fb75893cf8f9a1063a3a802d50c9623a1416
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198031
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Before commit 1e2e51607a (Try to use
CoWaitForMultipleHandles magic to handle COM message loop, 2025-01-10)
osl_waitCondition didn't adjust the timeout value in the COM message
processing loop. The abovementioned commit started to use a function
that pumps the message loop itself, but the code for manual pumping
wasn't removed (it has (likely) became dead).
This drops the dead code, and deduplicates the rest.
Change-Id: I0f7bbf8220792fbe42178c2689a065b5f38645d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180069
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Use the known string length into account (and I definitely like to
not rely on the undocumented implementation detail that OUString is
null-terminated).
Change-Id: I0e7478d25e802f8f8e31f02cf8d77613c1325bc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172170
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* Which also requires external/curl. But implicitly use --without-gssapi,
checking for it in configure.ac would fail with
> configure: error: could not find function 'gss_init_sec_context' required for GSSAPI
And building ExternalProject_curl needs to see the -pthread from
gb_EMSCRIPTEN_CPPFLAGS, otherwise linking Executable_soffice_bin would fail with
> wasm-ld: error: --shared-memory is disallowed by libcurl_la-easy.o because it was not compiled with 'atomics' or 'bulk-memory' features.
* By default, GetCABundleFile in include/systools/opensslinit.hxx will fail
now. (But to make https work, applications could bring along their own such
file in the Emscripten FS, in one of the places where GetCABundleFile checks for
it.) So, for Emscripten only, make failure of GetCABundleFile non-fatal in
InitCurl_easy.
* Some code in sw was erroneously hidden behind !ENABLE_WASM_STRIP_EXTRA (off
by default for Emscripten), but is needed with HAVE_FEATURE_CURL.
* See <https://emscripten.org/docs/porting/networking.html> for how to actually
use networking in an Emscripten application.
Change-Id: I2bbe9f3fd0e20143e18eb1e8104568b1c7a304de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172167
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Similar to commit 1f24d35033 (cppunittester:
use a dedicated desktop on Windows, 2023-07-09), this change allows to run
UI tests on Windows without them interferring with what you are doing.
The code testing LIBO_TEST_DEFAULT_DESKTOP environment variable to avoid
the separate desktop, and creating it, is extracted to a new function in
systools.
Change-Id: I6df3cb4ae581ae289e49b47d3135d01f632fbd95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170615
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
for SSL use by pyuno emailmerge
another alternative mechanism that could work is to generate one
with something like: "security find-certificate -a -p > cert.pem"
ref: https: //hynek.me/articles/apple-openssl-verification-surprises/
Change-Id: I8bff2ca5bbbb4f2c2333a67e0281dd4fa0b06405
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165599
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
In that environment, the shell:Startup shortcut created by us points to the
quickstart.exe under Program Files\WindowsApps\<StoreSpecificAppDir>\program.
The resulting shortcut can't launch, because of an inaccessible part in the
path (the protected WindowsApps directory). So the feature does not work in
the dialog.
Windows store apps should advertise the Windows startup task in the manifest.
Let's just hide the dialog entry in this case. A possible TODO would be to
provide a button instead, which would open the Startup Apps system applet,
similar to what we do for Default apps for file associations.
Change-Id: Ieafdf6d23ced96506b01c6b3cf9fb12904696df1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147735
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Building Executable_odbcconfig using VS2022 failed for me reproducibly
for some time, with
mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/lo/src/build/instdir/program/odbcconfig.exe". The file or directory is corrupted and unreadable.
make[1]: *** [C:/lo/src/core/dbaccess/Executable_odbcconfig.mk:10: C:/lo/src/build/instdir/program/odbcconfig.exe] Error 139
It is caused by linking odbccp32, and legacy_stdio_definitions required
by the latter with current versions of UCRT.
It seems to work OK for others; but being unable to find what's different
on my system, I have this workaround, using run-time loading instead.
Change-Id: Iab1fe7747ca6e677d89a120778ca805465a05611
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147627
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Building CppunitTest_basic_macros using VS2022 failed for me reproducibly
for some time, with
make[1]: *** [C:/lo/src/core/solenv/gbuild/LinkTarget.mk:841: C:/lo/src/build/workdir/LinkTarget/CppunitTest/test_basic_macros.dll] Error 139
It is caused by linking odbccp32, and legacy_stdio_definitions required
by the latter with current versions of UCRT.
It seems to work OK for others; but being unable to find what's different
on my system, I have this workaround, using run-time loading instead.
Change-Id: Ic4094398f7510bc281dfa96f980f29f12f09d7ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147626
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
BSTR is documented [1] to be prefixed by a 32-bit integer specifying
its length *in bytes* (not characters), so passing wchar_t* as BSTR
is wrong, and the length member of rtl_uString can't substitute the
proper BSTR length, since rtl_uString::length specifies length in
characters. Any code taking BSTR and using SysStringLen to get its
length would only get half of the passed OUString data.
In dbaccess/source/ui/dlg/adodatalinks.cxx, the abovementioned
error was implemented. OTOH, OLEVariant::getByteSequence() in
connectivity/source/drivers/ado/Aolevariant.cxx passed BSTR from
tagVARIANT to ctor of OLEString, which resulted in the BSTR being
freed in both dtors of OLEString and OLEVariant (the latter calls
VariantClear, which itself clears string when vtfield is VT_BSTR).
[1] https://docs.microsoft.com/en-us/previous-versions/windows/desktop/automat/bstr
Change-Id: Iedbd62b20133644258af3660616add7b63cac258
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131950
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Helps fixing uncaught exceptions introduced in commit
00eb9b8954.
TryCoCreateInstance returns HRESULT, because it allows to pass the info
to the caller, which must check the result (either HRESULT, or validity
of the reference) anyway.
In case of failure, the previous contents of com_ptr_ is kept, which
would be consistent with existing code in connectivity/ado replaced in
a follow-up patch.
Change-Id: I4c94695de96861ec312247acaa0c8fd35a23010a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127192
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...since de030cd7a2 "gbuild: Remove MSVC 2013
legacy code", so no longer treat it as such in compilerplugins. (Which caused a
few loplugin:includeform and loplugin:nullptr warnings.)
Change-Id: I99b42e76992e31aff56b417c05738d4d29e3faf9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112575
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> In file included from C:/lo-clang/core/vcl/win/dtrans/FmtFilter.cxx:37:
> C:/lo-clang/core/include\systools/win32/comtools.hxx(72,30): error: use 'template' keyword to treat 'QueryInterface' as a dependent template name [-Werror]
> : COMReference(p.QueryInterface<T>(t))
> ^
> template
Not sure why this only started to show up now with my clang-cl build on Windows.
(The Clang warning itself is available ever since <https://github.com/llvm/
llvm-project/commit/4e7a2c09b22bb04819702ac6b8ea8b59ca396fa5> "Improve recovery
(error + fix-it) when parsing type dependent template name without the
'template' keyword" from 2011; its "Also the error is downgraded to an ExtWarn
in Microsoft mode." implies that not requiring the "template" here is a non-
standard MSVC extension.)
Change-Id: I4f8e9d6fa80871fdd212417c1b935d76ffde34c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112192
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Debugging the test case from the latter bug report shows that indeed
the call to OleGetClipboard may fail first time, as jasonkres had
suspected in the former bug. So follow the suggestion in tdf#116983,
and retry the failing calls several times in case of failure.
Many thanks to Telesto for preparing a clear bug report with reliable
test case.
Co-authored-by: jasonkres
Change-Id: Ib3c497da830bc5faac586bcfe1eededa54bfa117
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111825
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>