On 2/20/2020 11:17 AM, Xiang Xiao wrote:
Do you include my patch?
Yes
And does the same config pass the build yesterday?
Yesterday I could not see some failures because $(Q) was still there.
So the archiver echo error output was being lost. Things have gotten
worse since yesterday, but I think most of the issues are on the ez80
side. Here are the problems that I see now:
1. The eZ80 COMPILE target generates the .obj file without using the
fully decorated object name. For example, when it is supposed to generate:
mkfatfs.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
It instead generates:
mkfatfs.obj
That should be easy to fix in the COMPILE and ASSEMBLE definitions.
2. The full path to the archive is
D:\Spuda\Documents\projects\nuttx\master\apps-fork\libapps.lib
But by the time it gets to the ZDS-II librarian, it becomes:
D:SpudaDocumentsprojectsnuttxmasterapps-forklibapps.lib
I haven't figures out where the backslashes are being lost yet.
I am expecting that this explicit GCC command option will cause failures
too:
./Makefile: $(call COMPILE, -fno-lto $<, $@)
That really should be dependent on CONFIG_ARCH_TOOLCHAIN_GNU. There
should be an issue opened up on that.
These all seem like simple things, but I haven't solved them all yet.
Makefiles are too difficult to debug!
Greg
