office-gobmx/soltools
Stephan Bergmann 707449adc9 -Werror,-Wdeprecated-declarations (sprintf, macOS 13 SDK): soltools
These occurrences of sprintf in C code don't normally trigger the deprecation
warning at least with recent macOS, because macOS by default now enables
_FORTIFY_SOURCE (see the code setting it in
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/_types.h
when originally unset), which for C code hides the declaration of sprintf (along
with its deprecation annotation) in
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/stdio.h
with a macro (expanding to __builtin___sprintf_chk) in
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/secure/_stdio.h.
But they started to trigger when I did an experimental -fsanitize=address build,
because
<b4f819086a>
"Disable source fortification on Darwin with AddressSanitizer" predefines
-D_FORTIFY_SOURCE=0 in that case.

While there might be ways to clean this code up to use something better than the
deprecated sprintf, don't bother too much with this 3rd-party, build-time--only
code and just silence any potential deprecation warnings.

Change-Id: I9f223a0ad50b2729b5d9af2db588fe9f82d0b07f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142534
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-10 14:50:53 +01:00
..
cpp -Werror,-Wdeprecated-declarations (sprintf, macOS 13 SDK): soltools 2022-11-10 14:50:53 +01:00
mkdepend -Werror,-Wdeprecated-declarations (sprintf, macOS 13 SDK): soltools 2022-11-10 14:50:53 +01:00
Executable_cpp.mk
Executable_makedepend.mk soltools: remove Package_inc and empty unistd.h nonsense 2013-05-10 17:56:24 +02:00
Makefile soltools conversion to gbuild 2012-09-29 15:48:52 +02:00
Module_soltools.mk soltools: remove Package_inc and empty unistd.h nonsense 2013-05-10 17:56:24 +02:00
README.md

Build Tools

Different build tools.