...since 1bb0e17712 "Fix autoconf>=2.70
gcc-wrapper breakage", which had the side effect of preventing various
deprecated function declarations in system headers (e.g., isascii in addition to
__isascii). This went unnoticed so far due to the traditionally lax handling of
missing function declarations in C, and only now started to cause
> conversion.c(94,9): error: call to undeclared function 'isascii'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> if ((isascii (*istr) && isprint (*istr)) || (*istr >= 0x80))
> ^
etc. 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".
Where undeclared functions have been used in Windows-only code, they have been
replaced with their __STDC__-declared counterparts, and for occurrences in
shared code Windows-only macro definitions have been introduced (as would have
done in the system headers too, if __STDC__ was not defined) to not clutter the
shared code with #ifdefs.
Also, for getpid (resp. _getpid), the #include <process.h> was apparently
missing from the upstream code, even without our __STDC__ hack in
external/libassuan/ExternalProject_libassuan.mk (but never caused errors until
now, either).
Change-Id: I7442394d0c6e633bca1f6c7331d7ee51651179a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133339
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>
Re-generated configure file gets confused & claims not finding C89-
compatible compiler for gcc-wrapper-building libassuan with msvc
underneath.
Work-around the problem by telling toolchain right off that this
_is_ a std c compliant compiler.
Change-Id: I4fa23673b790bc70a9294951df545c27f5236f81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127641
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.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>
In other external projects using libtool, we fix that by patching configure,
resetting hardcode_libdir_flag_spec[_CXX] at the end of the linux*) case block
that sets the Linux-specific value. But here we run autoreconf in
ExternalProject_libassuan, so that patch in configure would be overwritten. The
relevant code in configure comes from autoconf boilerplate, so we cannot just do
the same patch in configure.ac. But we can reset hardcode_libdir_flag_spec
sufficiently late in configure.ac so that things still work as intended.
Change-Id: Ic6c6123bcfe8bc2dac87812f919842519374abaa
Reviewed-on: https://gerrit.libreoffice.org/50959
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>
- 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>
Caolán McNamara