* Remove external/libgpg-error/w32-build-fixes-3.patch.1, which has
redundant contents with a part of external/libgpg-error/w32-build-fixes-5.patch.
Change-Id: I330b5f92717c1c5f6c0637940dfe7c3ac7e58b21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145169
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
This was apparently missing from d400009e7c
"gpg4libre: update gpgme, libassuan and libgpg-error" but went unnoticed so far
due to the traditionally lax handling of missing function declarations in C, and
only now started to cause
> logging.c(845,57): error: call to undeclared function 'getpid'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> (unsigned int)getpid (), pidsuf);
> ^
with clang-cl 15 trunk after
<https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626>
"[C11/C2x] Change the behavior of the implicit function declaration warning".
Change-Id: I66dc409f629d9bda807bc9cca21a8a5ecdda79be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133338
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
No idea why we just provided the platform flags when cross-
compiling. In the curious case, where the host platform is
detected as x86_64-pc-mingw32 per default and we actually
want to override it with x86_64-pc-cygwin, we don't do a
cross compile, but must override the host platform.
But there is additional special handling needed for the omitted
cross-platform build in the special case of --host=i686-pc-cygwin
and --build=x86_64-pc-cygwin, where we deliberatly ignore cross
building; Windows is already a slow build, so try to keep this
optimization (AMD64 can execute x86 binaries).
There is the theoretical case, where the externals config.guess
would have detected something else and that "magically" even
worked, while the LO detected triplet would fail, but this
should be fixed in the external in any way.
Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Cross compiling these libraries requires to supply the cross-
compiler via the CC_FOR_BUILD environment variable. Since we have
to use the gcc-wrappers, we now need two different invocations
with different inclues and libraries, but just have fixed
environment variables. Also, the CC_FOR_BUILD clashes with LO's
own variant, but that is easy to fix.
So this change includes:
- gcc-wrappers: new option --wrapper-env-prefix to add a prefix
to the environment variable names
- gcc-wrappers: new option --wrapper-print-cmdline to dump the
real command called, when a verbose build is executed
- gcc-wrappers: default to exe, if the output has no extension
- unify build flags for gpg related libraries
Change-Id: I4e6a6ba3c6e09237c8ffefa40ce61131290a3852
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102482
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
See instructions in solenv/gbuild/Trace.mk . This generates a file than
can be viewed e.g. in the Chromium tracing view.
Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The hope is that this should allow both system's libgpg-error.so.0 and
LO's bundled libgpg-error-lo.so.0 to be loaded by soffice.bin without
unintended hilarity.
Change-Id: I94498097a847b9756de86051798cb4ce022f6c83
Reviewed-on: https://gerrit.libreoffice.org/67012
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...which only patched configure.ac not configure, and the latter does not appear
to be regenerated from the former in ExternalProject_libgpg-error
Change-Id: Id0132ed8fd8ea3a5012e4a2bc309bd5f3983ad11
Reviewed-on: https://gerrit.libreoffice.org/50954
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
At least for cygwin64 windres, a wider number of cross-building
targets are supported. Utilize that for getting suitable versionrc
arch built, obviating the need to disable x86_64 on cyg32 and vice
versa.
Change-Id: I9770a3c1d6602a9747b5b3caa4961d66c471f4e4
Reviewed-on: https://gerrit.libreoffice.org/45763
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...to avoid having GCC as yet another prerequisite on Windows.
Cygwin 'man windres' states: "The default preprocessor argument is 'gcc -E
-xc-header -DRC_INVOKED'." Of those arguments, -E and -xc-header are not
relevant for Executable_cpp, so only -DRC_INVOKED is kept.
Additional arguments that turned out to be necessary are:
-I$(ATL_INCLUDE)
So that
#include <afxres.h>
in workdir/UnpackedTarball/libgpg-error/src/versioninfo.rc is found. (Not sure
how the original code using gcc found this.)
-+
So that using a C++ style comment in
#include "winres.h" // extract from windows header
in afxres.h does not cause a "Syntax error in #include" from Executable_cpp.
$(SOLARINC)
So that
#include "winres.h" // extract from windows header
in afxres.h is found. (Not sure how the original code using gcc found this.)
-DWINAPI_FAMILY=0
Because dlgs.h (included indirectly from afxres.h) contains
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
[...]
typedef struct tagCRGB
{
BYTE bRed;
BYTE bGreen;
BYTE bBlue;
BYTE bExtra;
} CRGB; /* RGB Color */
and the WINAPI_FAMILY_PARTITION conditional (defined in winapifamily.h) would be
true, causing the output to contain those "typedef struct tagCRGB ..." tokens
that windres apparently doesn't expect (failing with "windres: can't open file
`tagCRGB': No such file or directory"). (Not sure how the original code using
gcc avoided this.)
Change-Id: Ic2d031c72025f2e9dbde26c774215d2d2d0a43a9
Reviewed-on: https://gerrit.libreoffice.org/45334
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
* libgpg-error has some fixes around autogen & win32 critical sects
* gpgme has a few nice additions around keyinfos
* update lib versions to deliver
* remove external/libgpg-error/fix-autoconf-macros.patch -> this is
upstream now
Change-Id: I5a58ac15a485621c54ca1c7a768268e8a541256c
Reviewed-on: https://gerrit.libreoffice.org/37926
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
- serial-tests fix from Richard Jones' libguestfs (lgplv2+)
(needed for automake < 1.12)
- m4_esyscmd fix from slurm project (gplv2+), needed for
autoconf < 2.62 or so
- m4_argn from m4 sugar (gplv3+ with autoconf exceptions)
- AC_CHECK_FUNCS does not like nested macros, so outline dependend
AC_CHECK_HEADERS
- only build c and c++ bindings for gpgme, we don't need anything
else internally.
Change-Id: Ic65ca92119efda585ebc9acbfb7c6c2ac2585451
Reviewed-on: https://gerrit.libreoffice.org/34349
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Siegmund Gorr <siegmund.gorr@cib.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Xisco Fauli