#3669 Can no longer cross-compile for Windows (abort issue in preprocessor)

[Philipp Klaus Krause]

A few days ago, trying to cross-compile SDCC on GNU/Linux for Windows, I ran into:

make[3]: Entering directory '/tmp/sdcc-experiments/sdcc/support/cpp/gcc'
i686-w64-mingw32-g++  -fno-PIE -c   -g -O2     -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I. -I./. -I./../include -I./../sdbinutils/include -I./../libcpp/include -I./../libcody  -I./../libdecnumber -I./../libdecnumber/bid -I../libdecnumber -I./../libbacktrace  -I/tmp/boost_1_83_0 -I/tmp/boost_1_83_0  -I. -I. -I././support/util -I. -o diagnostic-color.o -MT diagnostic-color.o -MMD -MP -MF ./.deps/diagnostic-color.TPo diagnostic-color.cc
system.h:784:30: error: expected identifier before string constant
  784 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
      |                              ^~~~~~~~
system.h:784:30: error: expected ',' or '...' before string constant
system.h:784:30: error: expected identifier before string constant
  784 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
      |                              ^~~~~~~~
system.h:784:30: error: expected ',' or '...' before string constant
make[3]: *** [Makefile:1154: diagnostic-color.o] Error 1
make[3]: Leaving directory '/tmp/sdcc-experiments/sdcc/support/cpp/gcc'
make[2]: *** [Makefile:1531: all-gcc] Error 2
make[2]: Leaving directory '/tmp/sdcc-experiments/sdcc/support/cpp'
make[1]: *** [Makefile:917: all] Error 2
make[1]: Leaving directory '/tmp/sdcc-experiments/sdcc/support/cpp'
make: *** [Makefile:146: sdcc-libs] Error 2

AFAIR, I did not encounter this problem a few months ago.

I suspect that the the definition for abort happens before fancy_abort is defined. Maybe this issue is fixed in newer upstream cpp?

[Philipp Klaus Krause]

This prevents me from looking into [bugs:#3667].

[Philipp Klaus Krause]

Looks like the issue was patched in upstream GCC: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609514.html

[Philipp Klaus Krause]

Since [r14408], this works for me.

[Felix]

thanks