I am currently learning STM32F103 with Eclipse. I am facing a problem in linker stage, that I got linker error : undefined reference to `HAL_TIM_Base_Init'
Building target: TimerTest.elf
Invoking: GNU ARM Cross C++ Linker
arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -Og -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -fno-move-loop-invariants -Wall -Wextra -g3 -T "C:\Users\Gebruiker\Dropbox\CodeBase\Eclipse\TimerTest\SW4STM32\WS2812_TimerTest\STM32F103C8Tx_FLASH.ld" -Xlinker --gc-sections -L"C:\Users\Gebruiker\Dropbox\CodeBase\Eclipse\TimerTest\Src" -L"C:\Users\Gebruiker\Dropbox\CodeBase\Eclipse\TimerTest\Drivers\STM32F1xx_HAL_Driver\Src" -L"C:\Users\Gebruiker\Dropbox\CodeBase\Eclipse\TimerTest\Drivers\STM32F1xx_HAL_Driver\Inc" -L"C:\Users\Gebruiker\Dropbox\CodeBase\Eclipse\TimerTest\Inc" -Wl,-Map,"TimerTest.map" -Xlinker --cref --specs=nano.specs -o "TimerTest.elf" ./Src/WS2812.o ./Src/main.o ./Src/stm32f1xx_hal_msp.o ./Src/stm32f1xx_hal_tim.o ./Src/stm32f1xx_it.o ./Src/system_stm32f1xx.o ./Src/usb_device.o ./Src/usbd_cdc_if.o ./Src/usbd_conf.o ./Src/usbd_desc.o ./SW4STM32/startup_stm32f103xb.o ./Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_core.o ./Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_ctlreq.o ./Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_ioreq.o ./Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Src/usbd_cdc.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_cortex.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_dma.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_flash.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_flash_ex.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_gpio.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_gpio_ex.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_pcd.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_pcd_ex.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_pwr.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_rcc.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_rcc_ex.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_spi.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_spi_ex.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_tim.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_tim_ex.o ./Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_ll_usb.o
./Src/WS2812.o: In function `WS2812Init':
C:\Users\Gebruiker\Dropbox\CodeBase\Eclipse\TimerTest\Debug/../Src/WS2812.c:30: undefined reference to `HAL_TIM_Base_Init'
collect2.exe: error: ld returned 1 exit status
make: *** [makefile:64: TimerTest.elf] Error 1
Here is my code:
main.c
#include "main.h"
#include "WS2812.h"
#include "stm32f1xx_hal.h"
#include "usb_device.h"
int main(void)
{
WS2812Init();
while (1)
{
}
}
WS2812.h:
#ifndef INC_WS2812_H_
#define INC_WS2812_H_
#include <stm32f1xx_hal_gpio.h> // use gpio output
#include <stm32f1xx_hal_rcc.h>
#include <stm32f1xx_hal_tim.h> // use timer
// adopt gpio port & pin for following section
#define WS2812_GPIO_PORT GPIOB
#define WS2812_GPIO_PIN GPIO_PIN_12
#define ENABLE_GPIO_RCC() do{\
if(!__HAL_RCC_GPIOB_IS_CLK_ENABLED())\
__HAL_RCC_GPIOB_CLK_ENABLE();\
}while(0U)
static GPIO_InitTypeDef SW2812Pin = {
.Pin = WS2812_GPIO_PIN,
.Speed = GPIO_SPEED_FREQ_LOW,
.Mode = GPIO_MODE_OUTPUT_PP
};
#define SYS_CLOCK
// adopt timer configuration for following section
#define WS2812_SELECTED_TIMER TIM4
static TIM_HandleTypeDef ws2812TimerConfig;
void WS2812Init(void);
#endif /* INC_WS2812_H_ */
WS2812.c:
#include "WS2812.h"
void WS2812Init(void)
{
// init GPIO as output
ENABLE_GPIO_RCC();
HAL_GPIO_WritePin(WS2812_GPIO_PORT, WS2812_GPIO_PIN, GPIO_PIN_RESET);
HAL_GPIO_Init(WS2812_GPIO_PORT, &SW2812Pin);
// init timer
uint16_t targetFrequency = 1000; // 1kHz
const uint16_t preScaler = 360;
const uint16_t period = SystemCoreClock / (preScaler*targetFrequency);
// clear status register
__HAL_RCC_TIM4_CLK_ENABLE();
ws2812TimerConfig.Instance = WS2812_SELECTED_TIMER;
ws2812TimerConfig.Init.Prescaler = preScaler - 1;
ws2812TimerConfig.Init.Period = period;
ws2812TimerConfig.Init.CounterMode = TIM_COUNTERMODE_UP;
HAL_TIM_Base_Init(&ws2812TimerConfig); // <- linker can not find this function
__HAL_TIM_ENABLE(&ws2812TimerConfig);
}
This is my include structure:
main->
include"WS2812.h" ->
include stm32f1xx_hal_tim.h
The stm32f1xx_hal_tim.h is in the STM32F1xxHAL_DRIVER->inc, which is also put in the include path.
I also have added the include path in the project properties->C/C++ Build->Settings
for
GNU ARM Cross Assembler
GNU ARM Cross C compiler
GNU ARM Cross C++ Compiler
I searched in the internet found out this is a linker issue, that the linker can not find the proper source for linking.
What I have found in internet and tried:
added the folder which contents stm32f1xx_hal_tim.h and WS2812.h to project properties-> C/C++ Build -> GNU ARM Cross C++ Linker -> Libraries -> (-L)
added the folder which contents stm32f1xx_hal_tim.c and WS2812.c to project properties-> C/C++ Build -> GNU ARM Cross C++ Linker -> Libraries -> (-L)
Checked "stm32f1xx_hal_tim.h" -> property-> Exclude resource from build is unchecked (some people in the internet solved the problem by this)
Added "--specs=nano.specs" to the Linker options
All of above do not solve the problem.
Some people suggest to modify the makefile. But the project generate the makefile automatically, so I don't know where to start.
If anyone can provide a hint or solution, it will be very thanksful.
UPDATE 1:
Thanks Jacek Ślimok's input.
I didn't know that, I also need to doe the "exclude from build" for .c files. And I check in the file browser. The .c files are not check in this configuration. Do you mean like this?
excluded from Build
The stm32f1xx_hal_tim.c is under project->Driver->STM32F1xxHAL_Driver->Src
At this moment, the problem remains unsolved.
Another thing I noticed is that, the Eclipse read my stm32f1xx_hal_tim.c differently. When I open the stm32f1xx_hal_tim.c in Eclipse, it just give me a plane text like in normal notepad:
stm32f1xx_hal_tim.c
But other .c file like stm32f1xx_hal_gpio.c looks like normal.
stm32f1xx_hal_gpio.c
They are in the same folder. I don't know where and why this difference came from. Does this relative to my problem.
Update2
#Jacek Ślimok, I found out why the eclipse see the stm32f1xx_hal_tim.c as plane text. I accidentally turned on the Scalability setting in Preference-> Editor, stm32f1xx_hal_tim.c has relatively large file size, 161kB. After I change it back to default, Eclipse shows the file as normal. But the linker problem is still there...
In the main.c I also used HAL_GPIO_TogglePin() from stm32f1xx_hal_gpio.h/.c. The linker does not complain about that. Currently I can not tell the difference between these 2 files(stm32f1xx_hal_gpio and stm32f1xx_hal_tim) They are in the same folder, and included the same as well. But I can use the function for GPIO not for Timer.
But one thing can be sure:
I can use the macro in the stm32f1xx_hal_tim.h, so this is a linker problem.
I start this project base on another project, which was generated from STM32CubeMX. To practice the timer function I added the timer config to it, this is the point I got problem with the linker.
I hope these information can lead to more hints.
Update 3
I tried build the .c files separately
For stm32f1xx_hal.h.c:
00:09:16 **** Building Selected Files of configuration Release for project TimerTest ****
Info: Internal Builder is used for build
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -Wall -Wextra -g -DSTM32F103xB -DHSE_VALUE=8000000 "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Drivers\\CMSIS\\Include" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Drivers\\CMSIS\\Device\\ST\\STM32F1xx\\Include" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Drivers\\STM32F1xx_HAL_Driver\\Inc" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Inc" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Middlewares\\ST\\STM32_USB_Device_Library\\Class\\CDC\\Inc" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Middlewares\\ST\\STM32_USB_Device_Library\\Core\\Inc" -std=gnu11 -c -o "Drivers\\STM32F1xx_HAL_Driver\\Src\\stm32f1xx_hal_tim.o" "..\\Drivers\\STM32F1xx_HAL_Driver\\Src\\stm32f1xx_hal_tim.c"
00:09:17 Build Finished (took 285ms)
For WS2812.c:
00:11:23 **** Building Selected Files of configuration Release for project TimerTest ****
Info: Internal Builder is used for build
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -Wall -Wextra -g -DSTM32F103xB -DHSE_VALUE=8000000 "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Drivers\\CMSIS\\Include" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Drivers\\CMSIS\\Device\\ST\\STM32F1xx\\Include" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Drivers\\STM32F1xx_HAL_Driver\\Inc" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Inc" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Middlewares\\ST\\STM32_USB_Device_Library\\Class\\CDC\\Inc" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Middlewares\\ST\\STM32_USB_Device_Library\\Core\\Inc" -std=gnu11 -c -o "Src\\WS2812.o" "..\\Src\\WS2812.c"
00:11:23 Build Finished (took 275ms)
And for Main.c:
00:12:02 **** Building Selected Files of configuration Release for project TimerTest ****
Info: Internal Builder is used for build
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -Wall -Wextra -g -DSTM32F103xB -DHSE_VALUE=8000000 "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Drivers\\CMSIS\\Include" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Drivers\\CMSIS\\Device\\ST\\STM32F1xx\\Include" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Drivers\\STM32F1xx_HAL_Driver\\Inc" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Inc" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Middlewares\\ST\\STM32_USB_Device_Library\\Class\\CDC\\Inc" "-IC:\\Users\\Gebruiker\\Dropbox\\CodeBase\\Eclipse\\TimerTest\\Middlewares\\ST\\STM32_USB_Device_Library\\Core\\Inc" -std=gnu11 -c -o "Src\\main.o" "..\\Src\\main.c"
..\Src\main.c: In function '_Error_Handler':
..\Src\main.c:268:27: warning: unused parameter 'file' [-Wunused-parameter]
void _Error_Handler(char *file, int line)
^~~~
..\Src\main.c:268:37: warning: unused parameter 'line' [-Wunused-parameter]
void _Error_Handler(char *file, int line)
^~~~
In file included from ..\Src\main.c:55:0:
At top level:
C:\Users\Gebruiker\Dropbox\CodeBase\Eclipse\TimerTest\Inc/WS2812.h:36:26: warning: 'ws2812TimerConfig' defined but not used [-Wunused-variable]
static TIM_HandleTypeDef ws2812TimerConfig;
^~~~~~~~~~~~~~~~~
C:\Users\Gebruiker\Dropbox\CodeBase\Eclipse\TimerTest\Inc/WS2812.h:26:25: warning: 'SW2812Pin' defined but not used [-Wunused-variable]
static GPIO_InitTypeDef SW2812Pin = {
^~~~~~~~~
00:12:02 Build Finished (took 272ms)
There are few warning in the main.c, but they are not crucial.
Update4:
Thanks for Jacek Ślimok's input:
I found out that functions of stm32f1xx_hal_tim.c shows gray in file browser.
functions seems like not usable
But the functions in stm32f1xx_hal_gpio.c shows solid balck.
function in gpio.c are usable
Now the difference is there, just need to find out why.
Thanks in advance.
Best regards.
Doing #include stm32f1xx_hal_tim.h is not enough - it only causes your compiler not to complain, linker will still have a problem. Neither is adding a search path for the linker - this one you use mainly when you have static pre-compiled libraries that you explicitly link with the -l option. HAL is not a static library but rather a library you compile yourself.
To solve your problem, make sure you compile the corresponding source files - in this case stm32f1xx_hal_tim.c file and that it's later being linked. You mention that you use Eclipse and by default it generates a Makefile that causes all source files that you compiled in your project to also be linked. Therefore you mainly should check whether stm32f1xx_hal_tim.c is being compiled. One way to do that is to find the file in the Project Explorer, rightclick on it and select Resource Configurations -> Exclude from Build.... Make sure it's NOT checked. If it is, it is likely a whole directory is excluded from build which it should not be.
Another possibility is given function not being defined in any source file that is compiled or the function signature (name, return type and parameter types) don't match.
Yet another possibility (which in this case turned out to be the source of the issue) is that a portion of the file may not be compiled due to a #if/#ifdef preprocessor directive. In the OP's case this was caused by HAL_TIM_MODULE_ENABLED being undefined.
It is not relative to linker issue, but pre-processor.
As I mentioned, that I am building this code based on a project, which was generated from cubeMX. In the previous project, there is no timer used or configured. Than I started to write timer configuration. What I forgot is that to uncomment the #define HAL_TIM_MODULE_ENABLED in stm32f1xx_hal_conf.h. Which blocked all the implementation in stm32f1xx_hal_tim.c by pre-processor.
That is why eclipse shows all the function in stm32f1xx_hal_tim.c as gray color and not be able to be referenced.
And anyway, thanks Jacek Ślimok's effort!
Agree with Jacek Slimok, had this problem a while back, and for some reason I keep forgetting how to fix it. Googling the same solution every time if becoming annoying.
Just Skip to Solution
So you hit ctrl+space and autocomplete locates the function you want to call.
Yet in build, errors show up as "undefined reference to YOUR_FUNCTION_NAME".
So, you compile dependencies to become object files, but link object files to form an executable "firmware" generated by the compiler.
The "undefined reference" function called in main supposed to come from an object file which the linker can't locate.
Eclipse has a feature that allows you to exclude certain files from being "built" into object files. Thus the linker can't locate that dependency.
Solution:
This works for added folders or individual files in Eclipse.
So you have .c and .h files you created and you sometimes lump them in a folder you added to eclipse.
Right-click that added folder and hit properties.
In left menu select "Settings" under "C/C++ Build".
On the right, uncheck "Exclude resource from build".
Link to the picture below.
Folder Properties window in Eclipse:
Hope that helps everyone, and myself when I forget in a few days. Can you imagine the shock when I see my name on this post?
Related
I installed GCC (4.8.1) this morning and Eclipse Kepler (SR2). My Hello World compiled and ran fine, so I'm moving toward my goal of writing a C++ app using Boost. I installed Boost to "C:\Program Files\boost\boost_1_55_0" and added this path to Project>Properties>C/C++ General>Paths and Symols>[tab]Includes>GNU C++. However, when I compile, the path isn't showing up in the g++ command line, so understandably, the header file isn't getting found.
15:55:24 **** Incremental Build of configuration Debug for project BoostApp ****
Info: Internal Builder is used for build
g++ -O0 -g3 -Wall -c -fmessage-length=0 -o "src\\BoostApp.o" "..\\src\\BoostApp.cpp"
..\src\BoostApp.cpp:1:32: fatal error: boost/filesystem.hpp: No such file or directory
#include "boost/filesystem.hpp"
^
compilation terminated.
15:55:24 Build Finished (took 78ms)
I realize this is a newb question and spent a few hours searching around and finding mostly direction to set the path, which I've done. I've checked the install and the header file is there. I've also done my own command line compile adding "-I C:\Program Files\boost\boost_1_55_0" to the command line and GCC found the header file fine.
Not sure where I'm going wrong. As mentioned, it's a new install of GCC, Eclipse, and Boost, so maybe I went wrong somewhere during the install or maybe creating the project? Or just a newb question? Below is the app I'm compiling which I copied from rosettacode.com
#include "boost/filesystem.hpp"
#include "boost/regex.hpp"
#include <iostream>
using namespace boost::filesystem;
int main()
{
path current_dir("."); //
boost::regex pattern("a.*"); // list all files starting with a
for (recursive_directory_iterator iter(current_dir), end;
iter != end;
++iter)
{
std::string name = iter->path().filename().string();
if (regex_match(name, pattern))
std::cout << iter->path() << "\n";
}
}
I use Eclipse + ARM plugin to build my projects. When I needed to use in my project the StemWin library, I configured my IDE to use external library.
I set
Preferences -> C/C++ General -> Paths and Symbols
I added in "Library Paths" the link to my folder includes library.
I also added the name of my library in tab "Library".
I checked the settings in the compiler tab and I ascertained all should be good.
When I tried to build my project I got an error from linker:
cannot find -lMyLib.a Hello C/C++ Problem
I double checked the name of my library and link, all are correct. This is the output of my linker:
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -L"C:\lib"
-T"C:\arm_toolchain\stm32_workspace\Hello\LinkerScript.ld" -Wl,
-Map=output.map -Wl,--gc-sections -o "Hello.elf" #"objects.list" -lMyLib.a
What should I do from here?
I faced the same problem before.
-l:STemWin526_CM4_GCC.a
-L"C:\Edu_Workspace\STM32F4\stm32f4_bsp_template\Drivers\Middlewares\ST\STemWin\Lib"
Above are my working settings.
With -l:<archive file name> the colon : is important for archive file linking.
And -L will contain library path.
Also for stemwin make sure to compile with hardware floating point
-mfloat-abi=hard -mfpu=fpv4-sp-d16
the convention for the -l option of the linker (say you give -lMyLib.a as a linker option) is to search for a library file with "lib" prepended to the given name and .a (or .so) appended, i.e. your command line searches for a file libMyLib.a.{a,so} which is probably not how it's named.
Either you rename your library according to this convention or give it to the linker command line omitting -l (provided your IDE allows you to do so).
Looks like the problem is in -lMyLib.a which means you're trying to link a static library as a dynamic one.
To link a static lib you have to use its path as with ordinary .o files: ... /path/to/MyLib.a
and the resulting command line should look something like
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -L"C:\lib" -T"C:\arm_toolchain\stm32_workspace\Hello\LinkerScript.ld" -Wl,-Map=output.map -Wl,--gc-sections -o "Hello.elf" #"objects.list" /path/to/MyLib.a
UPDATE:
Although it might fix the issue, turns out it's not true:
-llibrary
-l library
...
Normally the files found this way are library files—archive files whose members are object files. The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined. But if the file that is found is an ordinary object file, it is linked in the usual fashion. The only difference between using an -l option and specifying a file name is that -l surrounds library with ‘lib’ and ‘.a’ and searches several directories.
(https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html)
I'm trying to use CUDA code inside MATLAB mex, under linux. With the "whole program compilation" mode, it works good for me. I take the following two steps inside Nsight:
(1) Add "-fPIC" as a compiler option to each .cpp or .cu file, then compile them separately, each producing a .o file.
(2) Set the linker command to be "mex" and add "-cxx" to indicate that the type of all the .o input files are cpp files, and add the library path for cuda. Also add a cpp file that contains the mexFunction entry as an additional input.
This works good and the resulted mex file runs well under MATLAB. After that when I need to use dynamical parallelism, I have to switch to the "separate compilation mode" in Nsight. I tried the same thing above but the linker produces a lot of errors of missing reference, which I wasn't able to resolve.
Then I checked the compilation and linking steps of the "separate compilation" mode. I got confused by what it is doing. It seems that Nsight does two compilation steps for each .cpp or .cu file and produces a .o file as well as a .d file. Like this:
/usr/local/cuda-5.5/bin/nvcc -O3 -gencode arch=compute_35,code=sm_35 -odir "src" -M -o "src/tn_matrix.d" "../src/tn_matrix.cu"
/usr/local/cuda-5.5/bin/nvcc --device-c -O3 -gencode arch=compute_35,code=compute_35 -gencode arch=compute_35,code=sm_35 -x cu -o "src/tn_matrix.o" "../src/tn_matrix.cu"
The linking command is like this:
/usr/local/cuda-5.5/bin/nvcc --cudart static --relocatable-device-code=true -gencode arch=compute_35,code=compute_35 -gencode arch=compute_35,code=sm_35 -link -o "test7" ./src/cu_base.o ./src/exp_bp_wsj_dev_mex.o ./src/tn_main.o ./src/tn_matlab_helper.o ./src/tn_matrix.o ./src/tn_matrix_lib_dev.o ./src/tn_matrix_lib_host.o ./src/tn_model_wsj_dev.o ./src/tn_model_wsj_host.o ./src/tn_utility.o -lcudadevrt -lmx -lcusparse -lcurand -lcublas
What's interesting is that the linker does not take the .d file as input. So I'm not sure how it dealt with these files and how I should process them with the "mex" command when linking?
Another problem is that the linking stage has a lot of options I don't understand (--cudart static --relocatable-device-code=true), which I guess is the reason why I cannot make it work like in the "whole program compilation" mode. So I tried the following:
(1) Compile in the same way as in the beginning of the post.
(2) Preserve the linking command as provided by Nsight but change to use "-shared" option, so that the linker produces a lib file.
(3) Invoke mex with input the lib file and another cpp file containing the mexFunction entry.
This way mex compilation works and it produces a mex executable as output. However, running the resulted mex executable under MATLAB produces a segmentation fault immediately and crashes MATLAB.
I'm not sure if this way of linking would cause any problem. More strangely, I found that the mex linking step seems to finish trivially without even checking the completeness of the executable, because even if I miss a .cpp file for some function that the mexFunction will use, it still compiles.
EDIT:
I figured out how to manually link into a mex executable which can run correctly under MATLAB, but I haven't figured out how to do that automatically under Nsight, which I can in the "whole program compilation" mode. Here is my approach:
(1) Exclude from build the cpp file which contains the mexFunction entry. Manually compile it with the command "mex -c".
(2) Add "-fPIC" as a compiler option to each of the rest .cpp or .cu file, then compile them separately, each producing a .o file.
(3) Linking will fail because it cannot find the main function. We don't have it since we use mexFunction and it is excluded. This doesn't matter and I just leave it there.
(4) Follow the method in the post below to manually dlink the .o files into a device object file
cuda shared library linking: undefined reference to cudaRegisterLinkedBinary
For example, if step (2) produces a.o and b.o, here we do
nvcc -gencode arch=compute_35,code=sm_35 -Xcompiler '-fPIC' -dlink a.o b.o -o mex_dev.o -lcudadevrt
Note that here the output file mex_dev.o should not exist, otherwise the above command will fail.
(5) Use mex command to link all the .o files produced in step (2) and step (4), with all necessary libraries supplied.
This works and produces runnable mex executable. The reason I cannot automate step (1) inside Nsight is because if I change the compilation command to "mex", Nsight will also use this command to generate a dependency file (the .d file mentioned in the question text). And the reason I cannot automate step (4) and step (5) in Nsight is because it involves two commands, which I don't know how to put them in. Please let me know if you knows how to do these. Thanks!
OK, I figured out the solution. Here are the complete steps for compiling mex programs with "separate compilation mode" in Nsight:
Create a cuda project.
In the project level, change build option for the following:
Switch on -fPIC in the compiler option of "NVCC compiler" at the project level.
Add -dlink -Xcompiler '-fPIC' to "Expert Settings" "Command Line Pattern" of the linker "NVCC Linker"
Add letter o to "Build Artifact" -> "Artifact Extension", since by -dlink in the last step we are making the output a .o file.
Add mex -cxx -o path_to_mex_bin/mex_bin_filename ./*.o ./src/*.o -lcudadevrt to "Post Build Steps", (add other necessary libs)
UPDATE: In my actual project I moved the last step to a .m file in MATLAB, because otherwise if I do it while my mex program is running, it could cause MATLAB crash.
For files needs to be compiled with mex, change these build option for each of them:
Change the compiler to GCC C++ Compiler in Tool Chain Editor.
Go back to compiler setting of GCC C++ Compiler and change Command to mex
Change command line pattern to ${COMMAND} -c -outdir "src" ${INPUTS}
Several additional notes:
(1) Cuda specific details (such as kernel functions and calls to kernel functions) must be hidden from the mex compiler. So they should be put in the .cu files rather than the header files. Here is a trick to put templates involving cuda details into .cu files.
In the header file (e.g., f.h), you put only the declaration of the function like this:
template<typename ValueType>
void func(ValueType x);
Add a new file named f.inc, which holds the definition
template<>
void func(ValueType x) {
// possible kernel launches which should be hidden from mex
}
In the source code file (e.g., f.cu), you put this
#define ValueType float
#include "f.inc"
#undef ValueType
#define ValueType double
#include "f.inc"
#undef ValueType
// Add other types you want.
This trick can be easily generalized for templated classes to hide details.
(2) mex specific details should also be hidden from cuda source files, since the mex.h will alter the definitions of some system functions, such as printf. So including of "mex.h" should not appear in header files that can potentially be included in the cuda source files.
(3) In the mex source code file containing the entry mexFunction, one can use the compiler macro MATLAB_MEX_FILE to selectively compile code sections. This way th source code file can be compiled into both mex executable or ordinarily executable, allowing debugging under Nsight without matlab. Here is a trick for building multiple targets under Nsight: Building multiple binaries within one Eclipse project
First of all, it should be possible to set up Night to use a custom Makefile rather than generate it automatically. See Setting Nsight to run with existing Makefile project.
Once we have a custom Makefile, it may be possible to automate (1), (4), and (5). The advantage of a custom Makefile is that you know exactly what compilation commands will take place.
A bare-bones example:
all: mx.mexa64
mx.mexa64: mx.o
mex -o mx.mexa64 mx.o -L/usr/local/cuda/lib64 -lcudart -lcudadevrt
mx.o: mxfunc.o helper.o
nvcc -arch=sm_35 -Xcompiler -fPIC -o mx.o -dlink helper.o mxfunc.o -lcudadevrt
mxfunc.o: mxfunc.c
mex -c -o mxfunc.o mxfunc.c
helper.o: helper.c
nvcc -arch=sm_35 -Xcompiler -fPIC -c -o helper.o helper.c
clean:
rm -fv mx.mexa64 *.o
... where mxfunc.c contains the mxFunction but helper.c does not.
EDIT: You may be able achieve the same effect in the automatic compilation system. Right click on each source file and select Properties, and you'll get a window where you can add some compilation options for that individual file. For linking options, open Properties of the project. Do some experiments and pay attention to the actual compilation commands that show up in the console. In my experience, custom options sometimes interact with the automatic system in a weird way. If this method proves too troublesome for you, I suggest that you make a custom Makefile; this way, at least we are not caught by unexpected side-effects.
I am trying to compile a project but I'm getting an error right away that it's not seeing the header files that are in some packages inside the project. Here is a picture, notice that it is not finding the AwarenessMoment.h file, however it is in there.
Here is the output:
**** Build of configuration Debug for project RoyOS ****
make all
Building file: ../src/royos/vision/ImageRecognizer.cpp
Invoking: GCC C++ Compiler
g++ -I/home/igvc/Documents/teamigvc/trunk/RoyOS -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/royos/vision/ImageRecognizer.d" -MT"src/royos/vision/ImageRecognizer.d" -o"src/royos/vision/ImageRecognizer.o" "../src/royos/vision/ImageRecognizer.cpp"
In file included from ../src/royos/vision/ImageRecognizer.cpp:8:0:
../src/royos/vision/ImageRecognizer.h:11:29: fatal error: AwarenessMoment.h: No such file or directory
compilation terminated.
make: *** [src/royos/vision/ImageRecognizer.o] Error 1
Anyone know why it's not seeing these header files?
Thanks
There's definitely something wrong with the include path given to the compiler. The preprocessor can't find the header from the source file you are attempting to compile.
I think you could fix this by replacing
#include "AwarenessMoment.h"
with
#include "../sensor/AwarenessMoment.h"
Either that or alter the compiler include path to include the sensor directory and use:
#include <AwarenessMoment>
The console output is:
**** Build of configuration Release for project Timertestnew ****
make all
Building file: ../main.cpp
Invoking: AVR C++ Compiler
avr-g++ -I"G:\arduino-1.0\hardware\arduino\cores\arduino" -DARDUINO=100 -Wall -Os -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields -fno-exceptions -mmcu=atmega328p -DF_CPU=16000000UL -MMD -MP -MF"main.d" -MT"main.d" -c -o "main.o" "../main.cpp"
Finished building: ../main.cpp
Building target: Timertestnew.elf
Invoking: AVR C++ Linker
avr-gcc --cref -s -Os -o"Timertestnew.elf" ./main.o -lArduinoCore -lm -Wl,-Map,Timertestnew.map,--cref -L"C:\Users\Akhil\workspace\Timertestnew" -mmcu=atmega328p
Finished building target: Timertestnew.elf
Create Flash image (ihex format)
avr-objcopy -R .eeprom -O ihex Timertestnew.elf "Timertestnew.hex"
Finished building: Timertestnew.hex
Invoking: Print Size
avr-size --format=avr --mcu=atmega328p Timertestnew.elf
AVR Memory Usage
----------------
Device: atmega328p
Program: 620 bytes (1.9% Full)
(.text + .data + .bootloader)
Data: 9 bytes (0.4% Full)
(.data + .bss + .noinit)
Finished building: sizedummy
**** Build Finished ****
The 'Problem' view output is:
Description Resource Path Location Type
Symbol 'EEARH' could not be resolved main.cpp /Timertestnew line 15 Semantic Error
Is it possible that eclipse ide is mistakenly showing this error while it compiles it fine?
How can I fix this?
Try to delete that problem marker from the problems view and rebuild your project (entirely, not just an incremental). If that fixes the issue, than it was simply an inconsistent state of the compiler.
However, if it does not fix the problem, then it is possible that the Eclipse editor uses a different parser (for content assist, etc.), that cannot handle something your compiler can. For this case, I would look around the C/C++ editor preferences related to errors, maybe it is turnable off (however, I don't program C/C++, so I cannot tell you what to look for).
The avr-gcc compiler uses its -mmcu command line argument to determine which IO header file to include (and therefore symbolic register definition including the EEARH EEPROM high address register being reported). Documentation here.
Eclipse may not be aware of this 'backdoor' preprocessor symbol definition (as it probably is using a different compiler for problem detection). From the console output it looks like the IO header file you need is: avr/iom328p.h which is included when the __AVR_ATmega328P__ preprocessor symbol is defined (see here). If you provide this symbol to Eclipse it should cause its compiler to pick up the correct file and define the relevant registers.