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:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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.
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.
Revision 13601 and up gives me:
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
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...
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:
... unless I explicitly pass the include path in CPPFLAGS
I would expect that that should not be necessary since this is $(PREFIX)/include
Thank you,
-Job
On Sat, Sep 03, 2022 at 09:50:45PM -0000, Job Bolle wrote:
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?
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.
Thank you Felix.
Log files are attached.
I got a bit further:
The difference between 13600 (working) and 13601 (not working) is this:
13600:
13601:
Revision 13601 adds this to device/lib/incl.mk:
In device/lib/Makefile.in, the following variables are defined before incl.mk is included:
The include paths get passed and the lib .c files get compiled into .rel files if I add
CPPFLAGS
to those rules, like this: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:With these changes, 13601 builds for me. The command that used to fail now works and looks like this:
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):
Regards,
-Job
Thanks Job.
On Tue, Sep 06, 2022 at 12:32:26PM -0000, Job Bolle wrote:
It's good practice to put preprocessor flags into CPPFLAGS, see [1].
These changes to the %.rel rules were clearly correct. I have committed
a patch. I hope it works for both GNU/Debian and MacOS.
Looking into it...
[1] https://www.gnu.org/software/automake/manual/html_node/Standard-Configuration-Variables.html
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
Related
Commit: [r13705]
On Thu, Sep 15, 2022 at 07:54:40PM -0000, Job Bolle wrote:
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
Related
Commit: [r13705]