Cannot build latest SDCC

[Job Bolle]

I can build trunk revision 13597 but not 13601 or later. (The 3 commits in between are not on trunk.)
At time of writing this, HEAD is 13688.

SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80_z80/z80n/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502 4.2.3 #13590 (Mac OS X x86_64)

Revision 13601 and up gives me:

/Users/Shared/Devel/Other/Z80/tools/sdcc/sdcc/bin/sdcc -mds390 --nostdinc --std-c11  -c ds390/../_atof.c
ds390/../_atof.c:29:19: error: no include path in which to search for ctype.h
ds390/../_atof.c:30:20: error: no include path in which to search for stdlib.h
ds390/../_atof.c:31:21: error: no include path in which to search for stdbool.h
ds390/../_atof.c:37: syntax error: token -> 'sign' ; column 13
make[4]: *** [ds390/_atof.rel] Error 1
make[3]: *** [objects] Error 2
make[2]: *** [model-ds390] Error 1
make[1]: *** [all] Error 2
make: *** [sdcc-device-lib] Error 2

I tried configuring with --disable-ds390-port but then I get the same issue for ds400.

I'm building on and for MacOS 12.5.1 using Xcode Version 13.4.1 (13F100)
Model Identifier: MacBookPro16,1
Processor Name: 6-Core Intel Core i7

job@flappy ~ % uname -a
Darwin flappy 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:25:27 PDT 2022; root:xnu-8020.141.5~2/RELEASE_X86_64 x86_64

[Felix]

Thanks Job.

The last two (strange) build issues we encountered were related to broken/incomplete "clean" and "distclean" rules. Did you make any use of them?

In case you did: an effective workaround is to build out of tree from a fresh clone: mkdir build; cd build; ../configure. Then delete build as needed.

In case you did not: I will figure out how to produce a meaningful log file and ask you to send it...

[Job Bolle]

Hi Felix,

Yes, I did make clean distclean. I always do this before checking out another revision.
I tried what you suggested, configure and make from a different directory, but I still get the same errors. When I tried building before, I had already made sure that SVN reported nothing as missing or unversioned or local-modified, ad reverted / deleted if it did.

Another thing that strikes me as odd (but maybe it is normal):

I use configure with a --prefix.
configure gives me this error:

configure: error: boost library not found (boost/graph/adjacency_list.hpp).

... unless I explicitly pass the include path in CPPFLAGS

job@flappy sdcc % ./configure --prefix=/Users/Shared/Devel/local CPPFLAGS=-I/Users/Shared/Devel/local/include

I would expect that that should not be necessary since this is $(PREFIX)/include

Thank you,
-Job

[Felix]

On Sat, Sep 03, 2022 at 09:50:45PM -0000, Job Bolle wrote:

Yes, I did make clean distclean. I always do this before checking out another revision.
I tried what you suggested, configure and make from a different
directory, but I still get the same errors. When I tried building
before, I had already made sure that SVN reported nothing as missing
or unversioned or local-modified, ad reverted / deleted if it did.

OK, thanks.

A (possibly) relevant difference between 13597 and 13601 is that build
errors in model-ds390 are no longer ignored. There are no such errors on
my system when building model-ds390 in either revision. I wonder what is
happening on your end.

Could you please send a log file produced similar to or as in

$ make -C device/lib clean
$ tmpfile=mktemp
$ make -C device/lib model-ds390 |& tee -a $tmpfile

for both revisions?

Another thing that strikes me as odd (but maybe it is normal):
[..]
I would expect that that should not be necessary since this is
$(PREFIX)/include

I can imagine that your suggestion would work in one case, but it might
have surprising side effects in another. Does anybody else do this? It
seems unusual (maybe adventurous) to me.

[Job Bolle]

Thank you Felix.
Log files are attached.
I got a bit further:

The difference between 13600 (working) and 13601 (not working) is this:

13600:

../../bin/sdcc -I../../../device/include -I../../../device/include/mcs51 -mds390 --nostdinc --std-c11 -c ../../../device/lib/_atof.c -o ds390/_atof.rel

13601:

/Users/Shared/Devel/Other/Z80/tools/sdcc-13601/sdcc/felix/bin/sdcc -mds390 --nostdinc --std-c11  -c ../../../device/lib/ds390/../_atof.c

• 13600 uses a relative path to sdcc, 13601 uses an absolute path. This is not the issue.
• 13600 passes 2 include paths, 13601 does not. This is part of the issue.

Revision 13601 adds this to device/lib/incl.mk:

CC = ${abs_top_builddir}/bin/sdcc
SDAR = ${abs_top_builddir}/bin/sdar

%.rel: %.c
    $(CC) $(CFLAGS) ${EXTRA_CFLAGS} -c $<

%.rel: ../%.c
    $(CC) $(CFLAGS) ${EXTRA_CFLAGS} -c $<

In device/lib/Makefile.in, the following variables are defined before incl.mk is included:

CPPFLAGS        = -I$(INCDIR) -I$(PORTINCDIR)
CFLAGS          = $(MODELFLAGS) --nostdinc --std-c11

The include paths get passed and the lib .c files get compiled into .rel files if I add CPPFLAGS to those rules, like this:

    $(CC) $(CFLAGS) $(CPPFLAGS) ${EXTRA_CFLAGS} -c $<

Alternatively, I could have added those include paths to CFLAGS.

However, I then run into the next problem: This puts the .rel next to the .c which is not where sdar is looking for them in the case of %.rel: ../%.c
For that rule, I have also added -o $@ to the command, so that the .rel file is put in the current dir when the .c is in the parent dir. So I end up with these rules at the bottom of incl.mk:

%.rel: %.c
    $(CC) $(CFLAGS) $(CPPFLAGS) ${EXTRA_CFLAGS} -c $<

%.rel: ../%.c
    $(CC) $(CFLAGS) $(CPPFLAGS) ${EXTRA_CFLAGS} -c $< -o $@

With these changes, 13601 builds for me. The command that used to fail now works and looks like this:

/Users/Shared/Devel/Other/Z80/tools/sdcc/sdcc/build-dir/bin/sdcc -mds390 --nostdinc --std-c11 -I../../../device/include -I../../../device/include/mcs51  -c ../../../device/lib/ds390/../_atof.c -o ds390/_atof.rel

This may not be The Solution but I think it provides nice diagnostics.

Now I can build up to 13687 but not 13690. This seems to be due to (a) completely different issue(s):

g++ -std=c++11 -c   -g -O2     -DIN_GCC    -fno-strict-aliasing -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  -DGENERATOR_FILE -I. -Ibuild -I../../../../support/cpp/gcc -I../../../../support/cpp/gcc/build -I../../../../support/cpp/gcc/../include  -I../../../../support/cpp/gcc/../libcpp/include  \
        -o build/gengenrtl.o ../../../../support/cpp/gcc/gengenrtl.cc
In file included from ../../../../support/cpp/gcc/gengenrtl.cc:22:
In file included from ../../../../support/cpp/gcc/system.h:243:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/new:92:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/cstdlib:85:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/stdlib.h:93:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:66:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/wait.h:110:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/resource.h:89:25: error: 'long type-name' is invalid
typedef __uint64_t      rlim_t;
                        ^
./auto-host.h:2679:16: note: expanded from macro 'rlim_t'
#define rlim_t long
               ^
In file included from ../../../../support/cpp/gcc/gengenrtl.cc:22:
../../../../support/cpp/gcc/system.h:556:20: error: functions that differ only in their return type cannot be overloaded
extern const char *strsignal (int);
             ~~~~~~^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/string.h:134:7: note: previous declaration is here
char    *strsignal(int __sig);
~~~~~~~~~^
2 errors generated.
make[3]: *** [build/gengenrtl.o] Error 1
make[2]: *** [all-gcc] Error 2
make[1]: *** [all] Error 2
make: *** [sdcc-libs] Error 2

Regards,
-Job

[Felix]

Thanks Job.

On Tue, Sep 06, 2022 at 12:32:26PM -0000, Job Bolle wrote:

[..]
$(CC) $(CFLAGS) $(CPPFLAGS) ${EXTRA_CFLAGS} -c $<
~~~
Alternatively, I could have added those include paths to CFLAGS.

It's good practice to put preprocessor flags into CPPFLAGS, see [1].

%.rel: ../%.c
$(CC) $(CFLAGS) $(CPPFLAGS) ${EXTRA_CFLAGS} -c $< -o $@

These changes to the %.rel rules were clearly correct. I have committed
a patch. I hope it works for both GNU/Debian and MacOS.

Now I can build up to 13687 but not 13690. This seems to be due to (a) completely different issue(s):

Looking into it...

[1] https://www.gnu.org/software/automake/manual/html_node/Standard-Configuration-Variables.html

[Job Bolle]

Looking into it...

Hi Felix,
You fixed it in [r13705].

I was trying to figure out what it would take for me to build 13690. After a bunch of trial and error I got it to build by passing -DHAVE_SYS_RESOURCE_H -DHAVE_STRUCT_TMS -DHAVE_CLOCK_T -DHAVE_STRSIGNAL to make.

Then I tried whether that would build HEAD (13709) which it did.

Then I wanted to write up a nice report, detailing which errors I got and which define would get rid of which errors and what the next errors would be, etc... In order to do this, I started building HEAD without any of those defines, and to my surprise it completed successfully.

Then I went back to figure out which commit fixed it and it turned out that I still got the same errors in 13704 but not in 13705.

Thank you,
-Job

[Felix]

On Thu, Sep 15, 2022 at 07:54:40PM -0000, Job Bolle wrote:

Looking into it...

Hi Felix,
You fixed it in [r13705].

Hi Job.

Thanks for your feedback. Sorry I did not find the time to check the
relation to the error you had reported, although I had suspected a
connection...

Glad it's working for you now.

cheers
felix