diff --git a/TODO b/TODO index a69b474fa16..5874aaa40f3 100644 --- a/TODO +++ b/TODO @@ -25,7 +25,7 @@ nuttx/: (12) Libraries (libc/, libm/) (10) File system/Generic drivers (fs/, drivers/) (9) Graphics Subsystem (graphics/) - (3) Build system / Toolchains + (1) Build system / Toolchains (3) Linux/Cywgin simulation (arch/sim) (4) ARM (arch/arm/) @@ -2027,109 +2027,6 @@ o Build system Status: Open Priority: Low. - Title: CONTROL-C CAN BREAK DEPENDENCIES - Description: If you control C out of a make, then there are things that can go - wrong. For one, you can break the dependencies in this scenario: - - - The build in a given directory begins with all of the compilations. - On terminal, this the long phase with CC: on each line. As each - .o file is created, it is timestamped with the current time. - - - The dependencies on each .o are such that the C file will be re- - compile if the .o file is OLDER that the corresponding .a archive - file. - - - The compilation phase is followed by a single, relatively short - AR: phase that adds each of the file to the .a archive file. As - each file is added to archive, the timestamp of the of archive is - updated to the current time. After the first .o file has been - added, then archive file will have a newer timestamp than any of - the newly compiled .o file. - - - If the user aborts with control-C during this AR: phase, then we - are left with: (1) not all of the files have bee added to the - archive, and (2) the archive file has a newer timestamp than any - of the .o file. - - So when the make is restarted after a control, the dependencies will - see that the .a archive file has the newer time stamp and those .o - file will never be added to the archive until the directory is cleaned - or some other dependency changes. - - NOTE: This may not really be an issue because the the timestamp on - libapps.a is not really used but rather the timestamp on an empty - file: - - .built: $(OBJS) - $(call ARCHIVE, $(BIN), $(OBJS)) - $(Q) touch $@ - - UPDATE: But there is another way that Control-C can break dependencies: - If you control-c out of the make during the apps/ part of the build, - the archive at apps/libapps.a is deleted (but all of the .built files - remain in place). You can see this in the make outout, for example: - - CC: ieee802154_getsaddr.c - make[2]: *** [Makefile:104: ieee802154_getsaddr.o] Interrupt - make: *** Deleting file '../apps/libapps.a' - - When you rebuild the system, the first file archived will recreate - libapps.a and set the timestamp to the current time. Then, none of - the other object files will be added to the archive because they are - all older.. or, more correctly, none of the other object files will - be addred because .built files remained and say that there is no - need to update the libapps.a file. - - The typical symptom of such an issue is a link time error like: - - LD: nuttx libsched.a(os_bringup.o): In function `os_bringup': - os_bringup.c:(.text+0x34): undefined reference to `nsh_main' - - This is becuase the libapps.a file was deleted and an new empty - libapps.a file was created (which the object containing nsh_main()). - The object containing nsh_main() will not be added because the - .built file exists and says that there is not need to add the - nsh_main() object to libapps.a. - - The work-around for now is: - - $ make apps_distclean - - One solution to this might be to making the special target - .PRECIOUS depend on apps/libapps.a. Then if make receives a - signal, it will not delete apps/libapps.a. This would have to - be done in all Makefiles. - - Status Open - Priority: Medium-High. It is a rare event that control-C happens at just the - point in time. However, when it does occur the resulting code may - have binary incompatiblies in the code taken from the out-of-sync - archives and cost a lot of debug time before you realize the issue. - - The first stated problem is not really an issue: There is already - the spurious .built file that should handle the described case: - If you control-C out of the build then the timestamp on the .built - file will not be updated and the archiving should be okay on the - next build. - - A work-around for the second stated problem is to do 'make clean' - if you ever decide to control-C out of a make and see that the - libapps.a file was deleted. - - UPDATE: This is a potential fix for the second problem in place - in in all Makefiles under apps/. This fix adds - - .PRECIOUS: $(BIN) - - to all Makefiles. It has not yet been confirmed that this fix - eliminates the dependency issue or not. - - Title: DEPENDENCIES OBJECT SUB-DIRECTORIES - Descripton: Dependencies do not work in directories that keep binaries in - a sub-directory like bin, ubin, kbin. - Status: Open - Priority: Medium-Low. Definitely a build issue once in awhile. - o Other drivers (drivers/) ^^^^^^^^^^^^^^^^^^^^^^^^