- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When building a new Nios II application the make dependencies are not working correct. This means that when changing a header file not all related .c files are compiled. Causing incorrect software!
I have attached an example project which demonstrates this:
- main.c calls a printf:
printf("Hello World %d\n",TEST2);
Thus main.c depends on test2.h for the macro TEST2 - main.c calls function myfunc() which is implemented in test2.c and calls a printf:
printf("Hello World %d\n",TEST2);
Thus test2.c is also depending on test2.h for the macro TEST2 - When changing the value of macro TEST2 in test2.h and saving the file and hereafter building the project does NOT recompile main.c and test2.c!
Thus the Make dependecies are not handled correctly and when examining the obj/main.d and obj/test2.d dependency files it can be seen that both files depend on test2.h!
Some how in the make process the dependecy files are not correct generated or interpreted
Causing incorect code which can only be corrected by doing a clean an full rebuild!
Environment used:
- Quartus Prime Version 20.1.1 Build 720 11/11/2020 SJ Standard Edition
- WSL 1 - Ubuntu 18.04 LTS - GNU Make 4.1 Built for x86_64-pc-linux-gnu
- Windows 10 version 1903 (OS Build 18362.1256)
- Eclipse Version: Mars.2 Release (4.5.2) Build id: 20160218-0600
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @MViss4,
Thank you for posting in Intel community forum, hope this message find you well and apologies for the delayed in response.
While trying to understand the situation, when there is an updates in the BSP files (i.e. test2.h) the nios ii apps project is not updates I assume, for that case I would suggest to rebuild (right click -> index -> rebuild) the apps project to see if that works.
If that does not help, maybe rebuilding the BSP with the following steps here.
Please do let us know if that helps.
Best Wishes
BB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @MViss4,
Greetings, unfortunately as we do not receive any further clarification on what is provided. Hence this thread will now be transitioned to community support. If you have new queries or further query on this thread, please feel free to open a new thread or reopen this thread to get support from us. Otherwise, the community users will further help you with doubts in this thread.
Best Wishes
BB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please note I have made case 00604188 in https://premiersupport.intel.com/ for this and it was confirmed that dependencies are not working.
And a fix is scheduled for the next release of Quartus.
Just for reference recently a colleague of mine has found a workaround as a rebuild is not really a sollution when you have to wait untill newlib is build which takes ~15min each time (with no build feedback!)
Fix incremental build (ctrl-b) when header file is updated
When a header file is updated the incremental build (ctrl-b) does not rebuild the objects that depend on the header file. So currently a clean + rebuild is needed.
This can be fixed with the following changes in the Makefile:
- In the Makefile for the project search for "-include $(APP_DEPS)" and adapt this to:
# Fix to always include Application dependency files
# Include the dependency files unless the make goal is performing a clean
# of the application.
#ifeq ($(firstword $(MAKECMDGOALS)),)
#ifeq ($(firstword $(MAKECMDGOALS)),app)
-include $(APP_DEPS)
#endif
#endif
- In the Makefile for the project search for "define compile.c" and adapt this to:
define compile.c
@$(ECHO) Info: Compiling $< to $@@
@$(MKDIR) $(@D)
$(CC) -MP -MMD -c $(APP_CPPFLAGS) $(APP_CFLAGS) -o $@ $< || (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)
@# Fix to correct paths in .d files
@dos2unix -q $(@:.o=.d)
@sed -e 's@[cC]:@/mnt/c@' -e 's@[dD]:@/mnt/d@' -e 's@\\@\/@g' -e 's@\/$$@\\@' -i $(@:.o=.d)
$(CC_POST_PROCESS)
endef
- In the Makefile for the project search for "define compile.cpp" and adapt this to:
define compile.cpp
@$(ECHO) Info: Compiling $< to $@@
@$(MKDIR) $(@D)
$(CXX) -MP -MMD -c $(APP_CPPFLAGS) $(APP_CXXFLAGS) $(APP_CFLAGS) -o $@ $< || (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)
@# Fix to correct paths in .d files
@dos2unix -q $(@:.o=.d)
@sed -e 's@[cC]:@/mnt/c@' -e 's@[dD]:@/mnt/d@' -e 's@\\@\/@g' -e 's@\/$$@\\@' -i $(@:.o=.d)
$(CXX_POST_PROCESS)
endef
-
In the Makefile for the project search for "define compile.cpp" and adapt this to:
define compile.s
@$(ECHO) Info: Assembling $< to $@@
@$(MKDIR) $(@D)
$(AS) -MP -MMD -c $(APP_CPPFLAGS) $(APP_CFLAGS) $(APP_ASFLAGS) -o $@ $< || (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)
@# Fix to correct paths in .d files
@dos2unix -q $(@:.o=.d)
@sed -e 's@[cC]:@/mnt/c@' -e 's@[dD]:@/mnt/d@' -e 's@\\@\/@g' -e 's@\/$$@\\@' -i $(@:.o=.d)
$(AS_POST_PROCESS)
endef
The -include $(APP_DEPS) command is never included due to the nested (wrong?) ifeq statements
"|| (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)" removes .o and .d file if gcc compiler returns with an error
The sed command converts the windows paths in the .d file to WSL path notation (e.g. C:\path\to\file is replaced by /mnt/c/path/to/file)
Warning: the sed command currently only supports C and D drives.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, this was very helpful. We of course cannot see your premier support case, so I have no idea how to tell if Intel have issued a fix, and if so what it was? But it seems they didn't change anything certainly until after 22.1 .
Couple of minor tweaks to the above:
1. You have an extra @ symbol at the end of the ECHO lines each of the define compile.*
2. The commented out ifeq lines for APP_DEPS can be replaced by ifeq (,$(filter clean,$(MAKECMDGOALS))) to continue to filter out the clean target.
3. You can make the sed command work with any drive letter by slightly tweaking the search to include any letter followed by colon and slash (necessary to stop it detecting the .h: and possibly .c: at the end of lines), with a capture group: 's@\([a-zA-Z]\):[\\/]@/mnt/\l\1/@'
define compile.c
@$(ECHO) Info: Compiling $< to $@
@$(MKDIR) $(@D)
$(CC) -MP -MMD -c $(APP_CPPFLAGS) $(APP_CFLAGS) -o $@ $< || (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)
@# Fix to correct paths in .d files
@dos2unix -q $(@:.o=.d)
@sed -e 's@\([a-zA-Z]\):[\\/]@/mnt/\l\1/@' -e 's@\\@\/@g' -e 's@\/$$@\\@' -i $(@:.o=.d)
$(CC_POST_PROCESS)
endef
define compile.cpp
@$(ECHO) Info: Compiling $< to $@
@$(MKDIR) $(@D)
$(CXX) -MP -MMD -c $(APP_CPPFLAGS) $(APP_CXXFLAGS) $(APP_CFLAGS) -o $@ $< || (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)
@# Fix to correct paths in .d files
@dos2unix -q $(@:.o=.d)
@sed -e 's@\([a-zA-Z]\):[\\/]@/mnt/\l\1/@' -e 's@\\@\/@g' -e 's@\/$$@\\@' -i $(@:.o=.d)
$(CXX_POST_PROCESS)
endef
define compile.s
@$(ECHO) Info: Assembling $< to $@
@$(MKDIR) $(@D)
$(AS) -MP -MMD -c $(APP_CPPFLAGS) $(APP_CFLAGS) $(APP_ASFLAGS) -o $@ $< || (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)
@# Fix to correct paths in .d files
@dos2unix -q $(@:.o=.d)
@sed -e 's@\([a-zA-Z]\):[\\/]@/mnt/\l\1/@' -e 's@\\@\/@g' -e 's@\/$$@\\@' -i $(@:.o=.d)
$(AS_POST_PROCESS)
endef
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, I can confirm this issue still occurs on the recently released Quartus Pro 22.4 so it looks like they still haven't fixed the incorrect Application Makefile generation.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page