SDCPP and CC1 naming and use, build changes

[bbbbbr]

Below is all using a new download of the repo fromr13858 and building in that clean tree with no previous builds. Let me know if I should split this to separate topics. Thanks!

I noticed some things and have a question about SDCPP the new CC1:

• When I build on Linux (64 bit) SDCPP does not seem to get built anymore.
• CC1 is not present in the Linux 64 bit snapshot build archives, but it is present in the Windows ones.

Is CC1 meant to be called directly from SDCC, or called through SDCPP?
Do I understand right that it is taking over the role as preprocessor?

Build things:
Also, at the end of a successful build many of the binaries no longer get copied into the bin directory, so I just ran the commands below.
Is there a new additional build command or stage that needs to be invoked to complete putting all the binaries in place? It has been about a year since I last built, so perhaps I am forgetting something.

cp src/sdcc bin
cp support/sdbinutils/binutils/sdar bin
cp support/sdbinutils/binutils/sdranlib bin
cp support/sdbinutils/binutils/sdobjcopy bin
cp support/sdbinutils/binutils/nm bin
cp support/cpp/gcc/cc1 bin

The lack of copy to bin also caused building to fail at the library stage, so I added --disable-device-lib to the configure to work around that (we don't use the library, so that is ok).

make[4]: Entering directory '/home/builduser/sdcc_4.3/sdcc-code-r13858-trunk/sdcc/device/lib'
if [ -f mos6502/Makefile ]; then \
  make -C mos6502 PORT=mos6502 || exit 1; \
fi || :
make[5]: Entering directory '/home/builduser/sdcc_4.3/sdcc-code-r13858-trunk/sdcc/device/lib/mos6502'
/home/builduser/sdcc_4.3/sdcc-code-r13858-trunk/sdcc/bin/sdcc -I./../../include -I. --std-c2x  -mmos6502 --max-allocs-per-node 25000 --opt-code-speed -c _ret.c -o _ret.rel
make[5]: /home/builduser/sdcc_4.3/sdcc-code-r13858-trunk/sdcc/bin/sdcc: Command not found
../incl.mk:153: recipe for target '_ret.rel' failed
make[5]: *** [_ret.rel] Error 127

This is my .configure. I'm building on a clean Ubuntu 16.04 virtual machine so that we can have a Linux Build that has broad GLIBC compatibility.

./configure \
  --enable-gbz80-port \
  --enable-z80-port \
  --enable-mos6502-port \
  --enable-mos65c02-port \
  --disable-mcs51-port \
  --disable-z180-port \
  --disable-r2k-port \
  --disable-r2ka-port \
  --disable-r3ka-port \
  --disable-tlcs90-port \
  --disable-ez80_z80-port \
  --disable-z80n-port \
  --disable-ds390-port \
  --disable-ds400-port \
  --disable-pic14-port \
  --disable-pic16-port \
  --disable-hc08-port \
  --disable-s08-port \
  --disable-stm8-port \
  --disable-pdk13-port \
  --disable-pdk14-port \
  --disable-pdk15-port \
  --disable-ucsim \
  --disable-doc \
  --disable-device-lib

[Philipp Klaus Krause]

I can only give a very rough idea here. The work was done by @felixs, who is familiar with the details and reasoning.

SDCC for a long time has had a preprocessor based on GCC 4.6.3. It had become clear, that to fix bugs in it, and to be able to support modern C standards, SDCC would need a new preprocessor. Various options were considered; in the end the chosen path was to replace it by one based on the one from GCC 12.1.0.
Since there had been major changes in the architecture of the preprocessor (e.g. it had since become more integrated into GCC, though not as tightly as what LLVM does), this also meant substantial changes in how the preprocessor is handled on the SDCC side.

While the binaries are no longer copied to sdcc/bin, sdcc/bin does contain scripts that do call the binaries.

For me, SDCC does fully build from source from svn on Debian GNU/Linux testing.

[bbbbbr]

Just to confirm - was your SDCC build test on a fully clean source tree/repo that hadn't built before?

I just tried again with these steps and still got a failure to copy binaries to bin at the end: (which then also causes the lib build error if I don't add --disable-device-lib to the configure to skip that stage)

wget --no-check-certificate https://downloads.sourceforge.net/project/sdcc/snapshot_builds/sdcc-src/sdcc-src-20230216-13890.tar.bz2
bunzip2 sdcc-src-20230216-13890.tar.bz2
tar xvf sdcc-src-20230216-13890.tar
cd sdcc
./configure \
  --enable-gbz80-port \
  --enable-z80-port \
  --enable-mos6502-port \
  --enable-mos65c02-port \
  --disable-mcs51-port \
  --disable-z180-port \
  --disable-r2k-port \
  --disable-r2ka-port \
  --disable-r3ka-port \
  --disable-tlcs90-port \
  --disable-ez80_z80-port \
  --disable-z80n-port \
  --disable-ds390-port \
  --disable-ds400-port \
  --disable-pic14-port \
  --disable-pic16-port \
  --disable-hc08-port \
  --disable-s08-port \
  --disable-stm8-port \
  --disable-pdk13-port \
  --disable-pdk14-port \
  --disable-pdk15-port \
  --disable-ucsim \
  --disable-doc \
  --disable-device-lib

make

And after the build completes there are several binaries in bin which are only a couple hundred bytes ( but do look correct in their pre-copy location).

~/sdcc_4.3/sdcc$ ls -lat bin
total 3204
drwxrwxr-x  2 builduser builduser   4096 Feb 15 23:48 .
-rwxrwxr-x  1 builduser builduser   6750 Feb 15 23:48 as2gbmap
-rwxrwxr-x  1 builduser builduser 550120 Feb 15 23:48 sdld
-rwxrwxr-x  1 builduser builduser 550120 Feb 15 23:48 sdld6808
-rwxrwxr-x  1 builduser builduser 550120 Feb 15 23:48 sdldgb
-rwxrwxr-x  1 builduser builduser 550120 Feb 15 23:48 sdldz80
-rwxrwxr-x  1 builduser builduser 290424 Feb 15 23:48 sdasgb
-rwxrwxr-x  1 builduser builduser 324384 Feb 15 23:47 sdasz80
-rwxrwxr-x  1 builduser builduser 289000 Feb 15 23:47 sdas6500
-rwxrwxr-x  1 builduser builduser  47728 Feb 15 23:41 makebin
-rwxrwxr-x  1 builduser builduser  30584 Feb 15 23:41 packihx
drwxrwxr-x 10 builduser builduser   4096 Feb 15 23:39 ..
-rwxrwxr-x  1 builduser builduser    213 Feb 15 23:38 sdobjcopy
-rwxrwxr-x  1 builduser builduser    208 Feb 15 23:38 sdranlib
-rwxrwxr-x  1 builduser builduser    208 Feb 15 23:38 sdnm
-rwxrwxr-x  1 builduser builduser    208 Feb 15 23:38 sdar
-rwxrwxr-x  1 builduser builduser    115 Feb 15 23:38 sdcpp
-rwxrwxr-x  1 builduser builduser    134 Feb 15 23:38 sdcc
-rw-rw-r--  1 builduser builduser    262 Feb 15 23:38 Makefile
-rw-rw-r--  1 builduser builduser    262 Sep  4 02:34 Makefile.in
-rw-rw-r--  1 builduser builduser    197 Sep  4 02:34 sdar.in
-rw-rw-r--  1 builduser builduser    123 Sep  4 02:34 sdcc.in
-rw-rw-r--  1 builduser builduser    104 Sep  4 02:34 sdcpp.in
-rw-rw-r--  1 builduser builduser    197 Sep  4 02:34 sdnm.in
-rw-rw-r--  1 builduser builduser    202 Sep  4 02:34 sdobjcopy.in
-rw-rw-r--  1 builduser builduser    197 Sep  4 02:34 sdranlib.in
-rw-rw-r--  1 builduser builduser     46 Jan 16  2000 README

~/sdcc_4.3/sdcc$ ls -l support/sdbinutils/binutils/sdar
-rwxrwxr-x 1 builduser builduser 2671352 Feb 15 23:41 support/sdbinutils/binutils/sdar

[Maarten Brock]

I also experience build failures when building from a fresh checkout on Ubuntu 20.04 LTS.

$ uname -v
#64~20.04.1-Ubuntu SMP Fri Jan 6 16:42:31 UTC 2023

$ ./configure -q --disable-pic14-port --disable-pic16-port
The following languages will be built: c

$ make > /dev/null 
In file included from /usr/include/string.h:495,
                 from sdcdb.h:47,
                 from sdcdb.c:24:
In function ‘strncpy’,
    inlined from ‘readCdb’ at sdcdb.c:418:11,
    inlined from ‘cmdFile’ at sdcdb.c:816:12:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sdcdb.c: In function ‘cmdFile’:
sdcdb.c:418:36: note: length computed here
  418 |           strncpy(currl->line, bp, strlen(bp)-1);
      |                                    ^~~~~~~~~~
cmd.c: In function ‘displayAll’:
cmd.c:3194:11: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
 3194 |       if (sym = symLookup (dsym->name, cctxt))
      |           ^~~
cmdpars.y: warning: 55 shift/reduce conflicts [-Wconflicts-sr]
cmdpars.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
asxxxx.c: In function ‘asxxxx_bfd_is_target_special_symbol’:
asxxxx.c:1068:55: warning: unused parameter ‘a’ [-Wunused-parameter]
 1068 | static bool asxxxx_bfd_is_target_special_symbol(bfd * a, asymbol * b)
      |                                                 ~~~~~~^
asxxxx.c:1068:68: warning: unused parameter ‘b’ [-Wunused-parameter]
 1068 | static bool asxxxx_bfd_is_target_special_symbol(bfd * a, asymbol * b)
      |                                                          ~~~~~~~~~~^
configure: WARNING: libdebuginfod is missing or unusable; some features may be unavailable.
In file included from /usr/include/string.h:495,
                 from makebin.c:31:
In function ‘strncpy’,
    inlined from ‘main’ at makebin.c:819:15:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ specified bound 2 equals destination size [-Wstringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
configure: WARNING: fixed-point is not supported for this target, ignored
configure: WARNING:
*** Makeinfo is missing or too old.
*** Info documentation will not be built.
/home/maarten/sdcc/support/cpp/gcc/configure: line 19705: test: =: unary operator expected
/home/maarten/sdcc/support/cpp/gcc/configure: line 24018: test: -gt: unary operator expected
/home/maarten/sdcc/support/cpp/gcc/configure: line 24019: test: -eq: unary operator expected
Links are now set up to build a native compiler for x86_64-pc-linux-gnu.
expr.cc: In function ‘unsigned int cpp_classify_number(cpp_reader*, const cpp_token*, const char**, location_t)’:
expr.cc:808:18: warning: format not a string literal and no format arguments [-Wformat-security]
  808 |        0, message);
      |                  ^
expr.cc:811:39: warning: format not a string literal and no format arguments [-Wformat-security]
  811 |           virtual_location, 0, message);
      |                                       ^
expr.cc:821:34: warning: format not a string literal and no format arguments [-Wformat-security]
  821 |      virtual_location, 0, message);
      |                                  ^
macro.cc: In member function ‘vaopt_state::update_type vaopt_state::update(const cpp_token*)’:
macro.cc:186:23: warning: format not a string literal and no format arguments [-Wformat-security]
  186 |      vaopt_paste_error);
      |                       ^
macro.cc:215:24: warning: format not a string literal and no format arguments [-Wformat-security]
  215 |       vaopt_paste_error);
      |                        ^
macro.cc: In function ‘cpp_macro* create_iso_definition(cpp_reader*)’:
macro.cc:3704:58: warning: format not a string literal and no format arguments [-Wformat-security]
 3704 |        cpp_error (pfile, CPP_DL_ERROR, paste_op_error_msg);
      |                                                          ^
macro.cc:3719:58: warning: format not a string literal and no format arguments [-Wformat-security]
 3719 |        cpp_error (pfile, CPP_DL_ERROR, paste_op_error_msg);
      |                                                          ^
ar: `u' modifier ignored since `D' is the default (see `U')
/bin/sh: /home/maarten/sdcc/support/cpp/missing: No such file or directory
configure: WARNING: 'missing' script is too old or missing
diagnostic.cc: In function ‘void fancy_abort(const char*, int, const char*)’:
diagnostic.cc:2027:52: warning: format not a string literal and no format arguments [-Wformat-security]
 2027 |       fnotice (stderr, diagnostic_kind_text[DK_ICE]);
      |                                                    ^
gcc.cc: In function ‘long unsigned int get_random_number()’:
gcc.cc:10577:12: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
10577 |       read (fd, &ret, sizeof (HOST_WIDE_INT));
      |       ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc.cc: In function ‘void do_report_bug(const char**, int, char**, char**)’:
gcc.cc:7789:9: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
 7789 |   write (fd, "\n//", 3);
      |   ~~~~~~^~~~~~~~~~~~~~~
gcc.cc:7792:13: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
 7792 |       write (fd, " ", 1);
      |       ~~~~~~^~~~~~~~~~~~
gcc.cc:7793:13: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
 7793 |       write (fd, new_argv[i], strlen (new_argv[i]));
      |       ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc.cc:7795:9: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
 7795 |   write (fd, "\n\n", 2);
      |   ~~~~~~^~~~~~~~~~~~~~~
SDCC.y:77.1-7: warning: POSIX Yacc does not support %expect [-Wyacc]
   77 | %expect 3
      | ^~~~~~~
In file included from /usr/include/string.h:495,
                 from SDCC.y:30:
In function ‘strncpy’,
    inlined from ‘yyparse’ at SDCC.y:2188:21:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying 252 bytes from a string of length 256 [-Wstringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘strncpy’,
    inlined from ‘yyparse’ at SDCC.y:2160:21:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying 252 bytes from a string of length 256 [-Wstringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SDCCval.c: In function ‘ulFromVal’:
SDCCval.c:2002:22: warning: passing argument 1 of ‘ullFromVal’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
 2002 |   return ullFromVal (val);
      |                      ^~~
In file included from SDCCsymt.h:657,
                 from SDCCast.h:29,
                 from common.h:43,
                 from SDCCval.c:26:
SDCCval.h:133:32: note: expected ‘value *’ {aka ‘struct value *’} but argument is of type ‘const value *’ {aka ‘const struct value *’}
  133 | unsigned long long ullFromVal (value *);
      |                                ^~~~~~~
gen.c: In function ‘opInfo’:
gen.c:330:23: warning: ‘%s’ directive output may be truncated writing up to 768 bytes into a region of size 60 [-Wformat-truncation=]
  330 |     snprintf(str, 64, "SYM:%s(%s:%d)",
      |                       ^~~~~~~~~~~~~~~
gen.c:330:23: note: directive argument in the range [-32768, 32767]
In file included from /usr/include/stdio.h:867,
                 from ./../common.h:21,
                 from ralloc.h:29,
                 from gen.c:29:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output between 9 and 782 bytes into a destination of size 64
   67 |   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   68 |        __bos (__s), __fmt, __va_arg_pack ());
      |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/string.h:495,
                 from aslink.h:35,
                 from lklist.c:34:
In function ‘strncpy’,
    inlined from ‘lkalist’ at lklist.c:985:9:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying between 4 and 11 bytes from a string of length 15 [-Wstringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘strncpy’,
    inlined from ‘lkglist’ at lklist.c:1264:9:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying between 3 and 4 bytes from a string of length 15 [-Wstringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘strncpy’,
    inlined from ‘lkglist’ at lklist.c:1274:25:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying between 4 and 11 bytes from a string of length 15 [-Wstringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lkmem.c: In function ‘summary’:
lkmem.c:366:37: warning: ‘%s’ directive writing up to 4095 bytes into a region of size 127 [-Wformat-overflow=]
  366 |                     sprintf(buff, "'%s'\n", Ram[j].Name);
      |                                     ^~
In file included from /usr/include/stdio.h:867,
                 from lkmem.c:18:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output between 4 and 4099 bytes into a destination of size 128
   36 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   37 |       __bos (__s), __fmt, __va_arg_pack ());
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lkmem.c:372:33: warning: ‘%s’ directive writing up to 4095 bytes into a region of size 127 [-Wformat-overflow=]
  372 |                 sprintf(buff, "'%s'\n", IRam.Name);
      |                                 ^~      ~~~~~~~~~
In file included from /usr/include/stdio.h:867,
                 from lkmem.c:18:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output between 4 and 4099 bytes into a destination of size 128
   36 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   37 |       __bos (__s), __fmt, __va_arg_pack ());
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lksdcclib.c: In function ‘buildlibraryindex_sdcclib’:
lksdcclib.c:151:37: warning: ‘%s’ directive writing 3 bytes into a region of size between 0 and 4095 [-Wformat-overflow=]
  151 |               sprintf (buff, "%s%s%c%s", lbnh->path, ModName, FSEPX, LKOBJEXT);
      |                                     ^~
In file included from /usr/include/stdio.h:867,
                 from lk_readnl.h:31,
                 from lksdcclib.c:36:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output 5 or more bytes (assuming 4100) into a destination of size 4096
   36 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   37 |       __bos (__s), __fmt, __va_arg_pack ());
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_rrulonglong.c:60: warning 151: using generic pointer <null> to initialize iTemp8
_rrslonglong.c:60: warning 151: using generic pointer <null> to initialize iTemp8
lcd390.c:67: warning 283: function declarator with no prototype
lcd390.c:89: warning 283: function declarator with no prototype
lcd390.c:94: warning 283: function declarator with no prototype
lcd390.c:99: warning 283: function declarator with no prototype
lcd390.c:103: warning 283: function declarator with no prototype
lcd390.c:107: warning 283: function declarator with no prototype
lcd390.c:111: warning 283: function declarator with no prototype
lcd390.c:115: warning 283: function declarator with no prototype
lcd390.c:119: warning 283: function declarator with no prototype
lcd390.c:124: warning 283: function declarator with no prototype
_rrulonglong.c:60: warning 151: using generic pointer <null> to initialize iTemp8
_rrslonglong.c:60: warning 151: using generic pointer <null> to initialize iTemp8
make[5]: rcD: Command not found
make[5]: [Makefile:41: ../build/ds400/libds400.lib] Error 127 (ignored)
Makefile:95: warning: overriding recipe for target 'Makefile'
Makefile:69: warning: ignoring old recipe for target 'Makefile'
Makefile:95: warning: overriding recipe for target 'Makefile'
Makefile:69: warning: ignoring old recipe for target 'Makefile'
Makefile:97: warning: overriding recipe for target 'Makefile'
Makefile:71: warning: ignoring old recipe for target 'Makefile'
Makefile:98: warning: overriding recipe for target 'Makefile'
Makefile:72: warning: ignoring old recipe for target 'Makefile'
Makefile:97: warning: overriding recipe for target 'Makefile'
Makefile:71: warning: ignoring old recipe for target 'Makefile'
Makefile:96: warning: overriding recipe for target 'Makefile'
Makefile:70: warning: ignoring old recipe for target 'Makefile'
Makefile:98: warning: overriding recipe for target 'Makefile'
Makefile:72: warning: ignoring old recipe for target 'Makefile'

$ make distclean > /dev/null 
make[1]: [Makefile:2376: local-distclean] Error 1 (ignored)
make[1]: [Makefile:2377: local-distclean] Error 1 (ignored)
make[1]: [Makefile:2378: local-distclean] Error 1 (ignored)
make[1]: [Makefile:2379: local-distclean] Error 1 (ignored)
make[1]: [Makefile:2380: local-distclean] Error 1 (ignored)
Makefile:98: warning: overriding recipe for target 'Makefile'
Makefile:72: warning: ignoring old recipe for target 'Makefile'
Makefile:95: warning: overriding recipe for target 'Makefile'
Makefile:69: warning: ignoring old recipe for target 'Makefile'
Makefile:95: warning: overriding recipe for target 'Makefile'
Makefile:69: warning: ignoring old recipe for target 'Makefile'
Makefile:97: warning: overriding recipe for target 'Makefile'
Makefile:71: warning: ignoring old recipe for target 'Makefile'
Makefile:98: warning: overriding recipe for target 'Makefile'
Makefile:72: warning: ignoring old recipe for target 'Makefile'
Makefile:97: warning: overriding recipe for target 'Makefile'
Makefile:71: warning: ignoring old recipe for target 'Makefile'
Makefile:96: warning: overriding recipe for target 'Makefile'
Makefile:70: warning: ignoring old recipe for target 'Makefile'
Makefile:98: warning: overriding recipe for target 'Makefile'
Makefile:72: warning: ignoring old recipe for target 'Makefile'
Makefile:95: warning: overriding recipe for target 'Makefile'
Makefile:69: warning: ignoring old recipe for target 'Makefile'
Makefile:95: warning: overriding recipe for target 'Makefile'
Makefile:69: warning: ignoring old recipe for target 'Makefile'
Makefile:97: warning: overriding recipe for target 'Makefile'
Makefile:71: warning: ignoring old recipe for target 'Makefile'
Makefile:98: warning: overriding recipe for target 'Makefile'
Makefile:72: warning: ignoring old recipe for target 'Makefile'
Makefile:97: warning: overriding recipe for target 'Makefile'
Makefile:71: warning: ignoring old recipe for target 'Makefile'
Makefile:96: warning: overriding recipe for target 'Makefile'
Makefile:70: warning: ignoring old recipe for target 'Makefile'
/bin/sh: line 0: cd: testsuite: No such file or directory
make[3]: [Makefile:3216: distclean] Error 1 (ignored)
/bin/sh: line 0: cd: testsuite: No such file or directory
make[3]: [Makefile:3217: distclean] Error 1 (ignored)
make[3]: [Makefile:3222: distclean] Error 1 (ignored)
make[1]: [Makefile:1256: local-distclean] Error 1 (ignored)
make[1]: [Makefile:1257: local-distclean] Error 1 (ignored)
make[1]: [Makefile:1258: local-distclean] Error 1 (ignored)
make[1]: [Makefile:1259: local-distclean] Error 1 (ignored)
make[1]: [Makefile:1260: local-distclean] Error 1 (ignored)

[bbbbbr]

Update: Did a build on a clean tree with source from 13911 and the build errors appear to be resolved now (at least for the subset of target platforms that GBDK uses)

[Aoineko]

With version 4.3.0rc1, I still get the CC1 error.
I don't know if this is the right place to mention it.

sdcpp.exe: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
compilation terminated.
at 1: warning 190: ISO C forbids an empty translation unit
subprocess error 1
Command failed: MSXgl\tools/sdcc/bin/sdcc -c -mz80 --vc -DTARGET=TARGET_ROM_32K -DMSX_VERSION=MSX_1 -IMSXgl\projects\samples/ -IMSXgl\engine/src -IMSXgl\engine/content -IMSXgl\tools/  --opt-code-speed -DAPPSIGN ./s_hello.c -o MSXgl\projects\samples/out/

I hope it will be fixed for the final version 4.3.0.

[Philipp Klaus Krause]

How did you install SDCC 4.3.0 RC1 (.zip? .exe installer? On what system (ReactOS? Windows? wine on GNU/Linux, etc?) Which version of it? Which architecture (x86. amd64)).

[Aoineko]

I installed sdcc-4.3.0-rc1-x64-setup.exe on a 64-bits version of Windows 10 Family.

That said, if I want to upgrade SDCC to 4.3.0 in my MSXgl library, I need to find a solution to embed SDCC without the user having to install another program as well.

In current version 4.2.0, everything needed to compile/build MSX application are included there: https://github.com/aoineko-fr/MSXgl/tree/main/tools/sdcc

[Philipp Klaus Krause]

I tested that configuration before uploading sdcc-4.3.0-rc1-x64-setup.exe (and tested it again just now, both time using Win 10 in a qemu VM, then opening a command prompt, the compiling a small test.c file via sdcc test.c).

So I wonder what is different in your case. Did you untick the box "Add C:\Program Files\SDCC\bin to path" in the installer (I left it ticket, which is the default)? How did you invoke sdcc?

[bbbbbr]

In the link you shared for where you are placing the sdcc files, it looks like you are missing the now required "libexec\sdcc\" directory that cc1 needs to be placed under.

For example if sdcc.exe is located and named as follows:
c:\TEMP\sdcc\bin\sdcc.exe

Then it should work if cc1 is located and named as follows (without the .exe extension) under:
c:\TEMP\sdcc\libexec\sdcc\cc1

More details in the following ticket:
https://sourceforge.net/p/sdcc/bugs/3571/

[Aoineko]

If cc1 need to be in libexec\sdcc\cc1 directory, why not put it there in the SDCC package?

[Aoineko]

I tryied to move cc1 in a libexec\sdcc\cc1 directory as described but I got the same error:
sdcpp.exe: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory

[Philipp Klaus Krause]

Any news on this? Did you get it to work? If not, can you provide the details I asked about yesterday?

[Aoineko]

Yes, I untick the box "Add C:\Program Files\SDCC\bin to path" in the installer.
I need my toolchain/library to be usable directly by cloning the Git repository (as is it currently the case with SDCC 4.2.0).

You can find MSXgl here: https://github.com/aoineko-fr/MSXgl
SDCC is embedded into the tools/sdcc/ directory.
The build tool use Node.js scripts (located in engine/script/js/) to call SDCC with the right parameters (depending on project configuration).

Here is an example for the example sample:
- Project root directory: projects/example/
- Build tool invoke SDCC first to compile each C module. E.g. D:\Dev\Private\MSX\MSXgl\tools/sdcc/bin/sdcc -c -mz80 --vc -DTARGET=TARGET_ROM_32K -DMSX_VERSION=MSX_1 -ID:\Dev\Private\MSX\MSXgl\projects\example/ -ID:\Dev\Private\MSX\MSXgl\engine/src -ID:\Dev\Private\MSX\MSXgl\engine/content -ID:\Dev\Private\MSX\MSXgl\tools/ --opt-code-speed --debug -DAPPSIGN ./example.c -o D:\Dev\Private\MSX\MSXgl\projects\example/out/
- Then the build tool invoke SDCC to link all modules together. D:\Dev\Private\MSX\MSXgl\tools/sdcc/bin/sdcc -mz80 --vc --no-std-crt0 -LD:\Dev\Private\MSX\MSXgl\tools/sdcc/lib/z80 --code-loc 0x4000 --data-loc 0xC000 --opt-code-speed --debug D:\Dev\Private\MSX\MSXgl\projects\example/out/crt0_rom32.rel D:\Dev\Private\MSX\MSXgl\projects\example/out/msxgl.lib D:\Dev\Private\MSX\MSXgl\projects\example/out/example.rel -o D:\Dev\Private\MSX\MSXgl\projects\example/out/example.ihx

All paths are dynamically generated relative to the project path.
MSXgl is used by many users, both on Windows and Linux.

Tell me if you need more information.

[bbbbbr]

If you want, you can use Process Explorer (by Sysinternals / Microsoft) filtered down to just show the sdcc and sdcpp executables. It allows seeing which paths they are actually searching (for sdcpp and cc1). I had success using that to figure out what was going on for our installs (so far).

[Philipp Klaus Krause]

Unfortunately, since we do now have that extra cc1 executable, just invoking sdcc without a suitable PATH (or whatever else is used on Windows to look for executables) being set no longer works. AFAIK, we need the directory where cc1 is, or the directory where libexec\sdcc\cc1 is to be in that PATH (or equivalent).
So if you don't want to install and set a suitable PATH (or equivalent) system-wide, this would have to be done by your build tool before invoking sdcc.
Since your build tool needs to know where sdcc is located anyway, it should also know where cc1 is, and thus be able to do this easily.

P.S.: I might be wrong here. I am not a preprocessor expert, and very rarely use Windows.

[Aoineko]

I'll give it a try, but I don't understand the story behind the /libexec/sdcc/cc1/.
In the SDCC 4.3.0 rc1 package, the cc1 tool is located in the /bin/ directory; If this is not the correct location, why isn't it already in the right place?
Will the trick of changing the path also work under Linux?

[Philipp Klaus Krause]

I don't know the details (@felixs does), but the high-level perspective is:

• Our old sdcpp was a fork of an ancient cpp (the preprocessor of gcc).
• We needed a newer one to be able to better support newer C standards.
• A year ago, when the decision as made, options were: using the preprocessor from current GCC, using the preprocessor from current clang, using Wave. We went with the first, which looked like the best choice at the time).
• cpp is now more tightly integrated into gcc (though not as much as the clang preprocessor is into clang), so we had to make some changes, including having separate sdcpp and cc1, similar to how this is handled in gcc.
• From today's perspective, Wave looks like it might be a better option (it is meant for creating stand-alone preprocessors); but a year ago, it was unmaintained and didn't support C standards newer than C99. The new maintainer has already added large parts of C2X support since.

[John Brandwood]

FWIW, I have a similar ambivalence to SDCC's decision to use the GCC 12 pre-processor, and have looked at alternatives for my own use within an SDCC toolchain.

Boost Wave is certainly one option for the SDCC developers to consider, but personally, I have decided to work on adding C23 support to Kiyoshi Matsui's MCPP (mcpp.sourceforge.net), another standalone C preprocessor project that has been unmaintained for a while and stuck at C99-compliance, but which is still used, and which is a current package in practically-all linux distributions.

The preprocessor changes from C99 -> C23 are easy to implement, and MCPP's source code is small, well-written, and seems easy to modify, all factors that I appreciate when looking at using someone else's code.

[bbbbbr]

Pardon my popping into this thread so much :)

So far(*1) we are using SDCC on Windows in arbitrary install locations without adding it to the system search PATH. As long as cc1 is relative to sdcpp in the way described earlier it has been working for use with gbdk.

(And it works for us so far on Windows 32 & 64 bit, Linux and MacOS)

*1: Tested up to build 14116. I'll trigger updated builds with our patches and check with those soon.

Edit: Built our patched 14186 and it is still working ok on Windows. (https://github.com/gbdk-2020/gbdk-2020-sdcc/actions/runs/5451673964)

An example from a (14110) build running in a Win 8 VM with no PATH updates to include any directories

c:\gb\gbdk-4.2.0\gbdk\examples\gb\template_minimal>..\..\..\bin\lcc -v -Wf--verbose -Wf-Wp-v  -o Example.gb main.c
"c:\gb\gbdk-4.2.0\gbdk\"bin/sdcc -msm83 --no-std-crt0 --fsigned-char --use-stdout -D__PORT_sm83 -D__TARGET_gb -Wa-pogn -I"c:\gb\gbdk-4.2.0\gbdk\"lib/gb -DINT_16_BITS --verbose -Wp-v -I"c:\gb\gbdk-4.2.0\gbdk\"include -c main.c -o C:\Users\IEUser\AppData\Local\Temp/lcc27680.o

sdcc: Calling preprocessor...
<snip>
sdcc: Generating code...
<snip>
Target: x86_64-w64-mingw32
<snip> 
[note, the line below is invoked by sdcpp]
c:/gb/gbdk-4~1.0/gbdk/bin/../libexec/sdcc/cc1 -E -quiet -nostdinc ... <snip>

sdcc: Calling assembler...
sdcc: sdasgb -pogn -plosgffw ... <snip>
"c:\gb\gbdk-4.2.0\gbdk\"bin/ihxcheck Example.ihx
"c:\gb\gbdk-4.2.0\gbdk\"bin/makebin -yN -Z Example.ihx Example.gb

It also still works fine if I copy that whole install to a new directory such as
"C:\some-new-path\gbdk..."

[Aoineko]

Sorry for the late reply.
By forcing the path in the build script, it works fine.
It's a pity to have to change the environment variables to make SDCC work, but at least it works.