- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have 7 calls to an external function within one source file. ONLY FOUR generate this error. I have tried copying one of the "good ones" over the bad ones.. no change.
I tried putting an extern.. line for the external function just above the function calls. No change.
I commented out these 4 lines to verify: I am not out of flash, and I am not out of RAM.
Help!
Solved! Go to Solution.
- Labels:
-
PSoC Creator Software
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The problem turned out to be (I am NOT making this up) that file was named
foo.C
instead of
foo.c
I have not had time to look it up, but I think the .C extension has some effect on C++ processor handling. Oh, YUCK.
Change the extension, and PRESTO, everything works like it is supposed to!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi StKr_1203736,
Would it be possible for you to share the project? This would help us in trying to pinpoint the issue.
Thanks and Regards,
Rakshith M B
Rakshith M B
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I received a request to 'share the project' to help with debugging. Considering the detailed NDA I had to sign to work on this, I think not.
I tried compiling just the file in question, which confirmed that this is not a compiler problem, it is a LINKER problem. Why would the linker successfully connect to some function calls, and not to others.. from the same source file?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is a LINKER error, not a compiler error. As best I can tell, the function xxxx_write() is being optimized out, despite calls in 7 functions, all in xxBoard.c. I think some of the calling functions are optimized out, too. Optimization is set for 'size' which makes sense - we don't have much room left. If I create a new xxxx_write() function in xxBoard.c, the problem goes away - and the linker does not even complain about xxxx_write() now being defined in two places.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you SOOO much for providing NO useful information. It is always nice to work with unresponsive, indifferent vendors. It really makes me want to NOT recommend you for future projects.
I have now reproduced this problem within a single source file: a function defined within a file is called ONLY within a file. The problem occurs with a forward reference declaration, and the definition AFTER the reference, and also with the definition BEFORE the reference. The linker must be optimizing out the function, so it cannot be found at link time.
Same error: prj:M0120:Build Error:undefined reference to <function_name>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
StKr,
I'm sadden that you have a negative impression about the product and the responses you have received so far. Please consider it has only been two days from your first post.
I'd like to help if I can.
The request to share the project is not unreasonable. However I understand your position with the NDA,
Is is possible to provide a stripped down version of the project that removes the proprietary IP so as not to violate the NDA?
If not, here are some suggestions:
I agree. It appears to be a LINKER problem.
You stated:
I have 7 calls to an external function within one source file. ONLY FOUR generate this error. I have tried copying one of the "good ones" over the bad ones.. no change.
This statement is a bit confusing. You state that there are 7 calls to the same exact external function in the same source (.c) file but only 4 of them report an error.
Are the 4 with errors the first 4 calls to the function? It may be possible that the LINKER phase stops after the first 4 errors and that ALL 7 calls have the issue but the LINKER stopped after only 4.
I tried putting an extern.. line for the external function just above the function calls. No change.
The declaration of the external function would normally be found in a .h file that is included in the early part of the source file with
#include "<external>.h" where <external> is the name of the source file with the external function.
Placing a "extern" declaration of the external function in the beginning of the source file is OK (not optimal). However, it doesn't help if the <external>.c file cannot be found in the LINKER path.
Please check if your source file for the external function is in the LINKER path.
When xxBoard.c is compiled, is there a => warning: implicit declaration of function 'xxx_write' [-Wimplicit-function-declaration] ?
If not, xxBoard.c can see the <external>.h to obtain the extern prototype. Therefore the LINKER can't find the source file for xxx_write() and provides the error.
As best I can tell, the function xxxx_write() is being optimized out, despite calls in 7 functions, all in xxBoard.c. I think some of the calling functions are optimized out, too. Optimization is set for 'size' which makes sense - we don't have much room left. If I create a new xxxx_write() function in xxBoard.c, the problem goes away - and the linker does not even complain about xxxx_write() now being defined in two places.
A called function where the code can execute never gets optimized out. The fact that you placed the external function inside of xxBoard.c and it worked AND it didn't complain: multiple definition of `xxx_write' proves that the LINKER can't find the <external>.c file and it was not compiled during the COMPILE phase.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
StKr,
I've kind of reproduced your issue.
I placed the following into a simple main.c
extern void xxx_write(); // declaration of an external function
// xxx_write() does not exist.
// This would be the same if the function that contains xxx_write() is not in the project build (hence the LINKER) path.
main()
{
...
xxx_write(); // 1st call
xxx_write(); // 2nd call
xxx_write(); // 3rd call
xxx_write(); // 4th call
xxx_write(); // 5th call
xxx_write(); // 6th call
xxx_write(); // 7th call
...
}
Here is the LINKER errors I get:
.../main.c:111: undefined reference to `xxx_write'
.../main.c:112: undefined reference to `xxx_write'
.../main.c:113: undefined reference to `xxx_write'
.../main.c:114: undefined reference to `xxx_write'
.../main.c:115: undefined reference to `xxx_write'
I get 5 errors out of the 7 calls to the function before the LINKER stops.
One problem identified.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The problem turned out to be (I am NOT making this up) that file was named
foo.C
instead of
foo.c
I have not had time to look it up, but I think the .C extension has some effect on C++ processor handling. Oh, YUCK.
Change the extension, and PRESTO, everything works like it is supposed to!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
StKr,
I'm glad you found the issue!
I've reproduced your issue with the function in foo.C. Same results. This is because the file does not get called for compiling.
This is either a Creator IDE issue (case sensitive for the extension) or an issue with the GCC C compiler.
From a search on the internet, I did not see specific requirements that the source code file MUST be lowercase 'c'. In general, C file processing is suppose to be case-insensitive. This is why two files named "Thisfile.c" and "thisfile.c" can exist in different directories and be loaded into the IDE. Each would compile separately but the LINK phase should complain or at best yield only one compile result before the LINK phase.
I changed foo.C to foo.c and it worked as you noted.
I hope Cypress is monitoring this discussion. Fix in Creator 4.5?
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi LePo_1062026, StKr_1203736,
I checked with the internal team regarding this issue.
Although the Windows environment is case insensitive regarding the file names and extensions, PSoC Creator could be explicitly looking for lowercase .c files because according to the GCC documentation, uppercase .C is meant to be C++. This could be the reason for the issue.
Unfortunately, there are no plans of changing this feature in PSoC Creator at the moment.
Thanks and Regards,
Rakshith M B
Rakshith M B