Undefined reference to function / Cannot detect target name

[Salieri]

Hi,

1. I’m getting an “undefined reference to function” error, but the function is properly referenced in the header file which is included in the c file. So to recap, I have function “fcn()” which is located in the “function.c” and declared in “function.h”. “function.h” is included in the “task.c”, but the linker is throwing “undefined reference to fcn()” error in “task.c” and the build is not successful. If I uncomment “fcn()” from “task.c” the compilation is successful.
2. I am getting an “Cannot detect target name for makefile” warning when attempting to compile. Compile is successful, but I would like to know why the warning is present.

Regards

[support]

Hi,

The first error can be caused by the missing ‘extern “C”‘ around the headers if you are using the function from the C++ code.

Regarding the second error, it is hard to tell without a screenshot. Please attach one and we should be able to help you.

[Salieri]

Hi,

First of all, thanks for the help!

As for the undefined reference error – all files are .c, none are .cpp. The funny thing is – when typing the code in task.c, IntelliSense properly detects the included header file and auto-completes to the function name. It’s just at compile/link time when the error appears.

I’ve double checked if the definition and declaration of the functions match, and they do.

I have a hunch that my problem is somehow linked to the object files as proposed here, but I don’t know how to tackle this issue in the VisualStudio/GDB environment:

http://stackoverflow.com/questions/24702645/c-undefined-reference-to-function-error-with-linked-files

I’ll add a screenshot of the second issue as soon as I get back home.

[EDIT]

Also please note that I have made modifications to the linker script and the Makefile based on the Bootloader tutorial implementation on your website (http://visualgdb.com/tutorials/arm/bootloader/). Is it possible that something went awry during this process? If so, is there any way for me to regenerate the linker script and the Makefile to see if that fixes things?

• This reply was modified 8 years, 7 months ago by Salieri.

[support]

Hi,

OK, if the extern “C” is not the reason, you would need to have a detailed look at what exactly is being linked. Please identify one function that is reported unresolved and then do the following:

• Identify the file where it is defined
• Ensure via the build log that the file is linked into the final binary
• Using the nm tool from your toolchain double-check that the .o file actually defines the function and the name matches the error message
• If this does not help, enable the Map file generation and check the Map file to references to the function.

If nothing helps, please post your map file, your build log and the nm output here along with the function name you are tracing so that we could give further advice.

[Salieri]

I have found the source of  the problem. It was located between the keyboard and the chair.

As it turns out, the definition and the declaration of the function did indeed not match. There was a typo in the function name defined in the header file (think fcn_recieve() instead of fcn_receive() ) and so naturally, when I was trying to call fcn_receive() from another source file, it was undefined. I think I’m gonna crack open a bottle of whiskey, drink to your health and then bash myself over the head with it. Thank you for your patience.

Regarding the warning about the Makefile which I mentioned in the first post. This is the warning line generated by the compiler:

2>—— Build started: Project: SCADA_FreeRTOS, Configuration: Debug Win32 ——
2>VisualGDB : warning : Cannot detect target name for: C:\Users\bjerm\Documents\Personal\Software\SCADA_FreeRTOS\SCADA_FreeRTOS\Makefile

As I said, the project compiles successfully, so the issue is not pressing, but I am wondering why it happens. You mentioned that you require a screenshot, but this is the exact description of the warning.

 

• This reply was modified 8 years, 7 months ago by Salieri.

[support]

Hi,

No problem. “Similar, but not quite the same” is the most annoying type of problem.

The “cannot detect target name” message means that VisualGDB was unable to locate the “TARGETNAME := xxx” line in the Makefile and it won’t be able to automatically add the project output to the list of inputs of another project that is referencing it. If you have modified Makefiles manually, this makes sense. If you don’t rely on this feature, you can simply ignore the warning.

 

[larrymccutchan]

I have the same problem with “Cannot detect target name for “…. Makefile”

The makefile was generated by VisualGDB but was modified. I can paste a copy of the full make file if it helps. Otherwise, here is the first few lines that demonstrate the setting of the TARGETNAME.

<< Makefile insert >>

#Generated by VisualGDB project wizard.
#Note: VisualGDB will automatically update this file when you add new sources to the project.
#All other changes you make in this file will be preserved.
#Visit http://visualgdb.com/makefiles for more details

#VisualGDB: AutoSourceFiles #<— remove this line to disable auto-updating of SOURCEFILES and EXTERNAL_LIBS

TARGETNAME := SyringeManager
#TARGETTYPE can be APP, STATIC or SHARED
TARGETTYPE := APP

 

[support]

Hi,

We would recommend generating a new project from scratch, ensuring that it does not have the problem and then comparing the Makefiles side-by-side and merging the differences step-by-step. This should help quickly understand what exact difference causes the problem.

[larrymccutchan]

I tried recreating a new project from scratch.The problem did not present itself when creating the new project when creating the project.

However, it did present itself as soon as I add a library dependency using the Visual Studio’s “Build Depedencies->Project Dependencies”. The problem comes from adding a dependency to the project.

The build output without the dependency was:

1>—— Build started: Project: SystemControl, Configuration: CrossComp Win32 ——
1> VisualGDB: Sending 10 updated source files to build machine…
1> VisualGDB: Run “make CONFIG=CrossComp” in directory “/tmp/VisualGDB/c/tfs/Frankenstation/src/SystemControl” on lam@localbuildhost (SSH)
1> mkdir CrossComp
1> g++ -ggdb -ffunction-sections -O0 -DDEBUG=1 -c main.cpp -o CrossComp/main.o -MD -MF CrossComp/main.dep
1> g++ -o CrossComp/SystemControl -Wl,-gc-sections -Wl,–start-group CrossComp/main.o -Wl,–rpath=’$ORIGIN’ -Wl,–end-group
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

The build output with the dependency is:

1>—— Rebuild All started: Project: SystemControl, Configuration: LinuxDebug Win32 ——
1> VisualGDB: Run “make CONFIG=LinuxDebug clean” in directory “Frankenstation/src/SystemControl” on lam@localbuildhost (SSH)
1> rm -rf LinuxDebug
1> rm -rf cg
1>VisualGDB : warning : Cannot detect target name for: C:\tfs\Frankenstation\src\SystemControl\Makefile
1> VisualGDB: Sending 10 updated source files to build machine…
1> VisualGDB: Run “make CONFIG=LinuxDebug” in directory “Frankenstation/src/SystemControl” on lam@localbuildhost (SSH)
1> mkdir LinuxDebug
1> g++ -std=c++14 -ggdb -ffunction-sections -O0 -I../include -I../Framework/include -I../Framework/cg -DDEBUG=1 -DUSE_SIM=1 -c main.cpp -o LinuxDebug/main.o -MD -MF LinuxDebug/main.dep
1> g++ -o LinuxDebug/SystemControl -static-libstdc++ -L/usr/local/lib -Wl,–start-group LinuxDebug/main.o -lboost_system -lboost_date_time -lpthread ../Framework/LinuxDebug/libframework.a -Wl,–rpath=’$ORIGIN’ -Wl,–rpath=’$ORIGIN/../../Framework/LinuxDebug/’ -Wl,–end-group
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

 

[support]

Hi,

This means that the problem happens when VisualGDB tries to parse the referenced project’s Makefile. Please try doing the same steps with it: re-create it from scratch and merge the changes one-by-one. Sorry about the inconvenience.

[Author]

Posts