PSoc Creator 4.4, ARM GCC 5.4: extraneous "prj.M0120:Build Error undefined reference to xxx" errors.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
StKr_1203736
Level 3
Level 3
First like received 10 replies posted 10 sign-ins

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!

0 Likes
1 Solution

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!

View solution in original post

0 Likes
9 Replies
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

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

Thanks and Regards,
Rakshith M B
0 Likes

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?

0 Likes

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.

0 Likes

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>

0 Likes

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

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

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

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

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!

0 Likes

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

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

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

Thanks and Regards,
Rakshith M B
0 Likes