Totally depends on what the Makefile is doing, and what exact error you get!
I suggest: Start by trying to understand what the specific rule (command) that fails is actually trying to do...
Makefiles consist of rules which describe how to carry out commands. For example, a rule might explain how to compile a single source file, or how to link all the object files into the executable, or perhaps how to clean up all the object files. A rule has the following form
The .a files aren't used at runtime. They are needed by the linker. At some point, you need to pass in a parameter to the compiler to link the library.
For example, if you have libblah.a, you pass in -lblah in the compiler command line.
Compiler generates object file from each translation unit. For example, the 'main.o' from 'main.cpp'.
Linker combines object files into executable.
However, it is possible to pack (some) object files into "library file" and give that to linker (in addition to other object files).
There are two library file formats: archive and shared object. They are packed a bit differently.
The archive, .a, is simple concatenation. The shared object, .so, is used with dynamic linking.
Since libraries are not simply object files, the linker has to be told to read then as libraries. The -l option does that.
When you give that -lblah, the linker looks for libblah.so and libblah.a. With -L option you can add additional paths, locations that linker will check for libraries.
The -Lsomewhere -lblah would be in the LIBS variable.
Neither stld1553.a nor stld1553drvapi_win32.a seem to use the "libname.a" naming convention.
The stld1553drvapi_win32.a seems to contain at least the SitalSDK.o.
actually i linked the .a files in application project settings:
properties-->c/c++ build-->settings-->arm v8 Linux g++ linker-->miscellaneous-->
other objects--> here i put stld1553.a and stld1553drvapi_win32.a
so i think it is equivalent to -l option. or does it?
None of the libs you've specified (stld1553.a, stld1553drvapi_win32.a) contain the function:
Sital_GetDeviceMemSize(void*, unsignedint*)
You could search for that function, and check that the file it's in is compiled and added to one of the libraries.
I realize you may be new to C/C++, but we've all had this baptism of fire. Just take it one step at a time.
[EDIT]
You check by:
1. search your source for that function implementation
2. touch the file and run make. Touch updates the timestamp of the file, and make will recompile it.
3. ensure the file is recompiled and added to a static lib, make note of the name.
4. we expect the library name will be one of the ones listed above.
5. ensure there is only one copy of this library on your system, or you'll never be quite sure which one it's using.
actually i linked the .a files in application project settings:
properties-->c/c++ build-->settings-->arm v8 Linux g++ linker-->miscellaneous-->
other objects--> here i put stld1553.a and stld1553drvapi_win32.a
In other words you do have IDE, where you make choices and the IDE generates Makefile for you.
That is good; the syntax of Makefile should be correct (unlike in manually written ones).
The problem is thus in the choices you have done -- in the content you told IDE to put into Makefile.
17:49:30 **** Incremental Build of configuration Debug for project CodeSample ****
make all
'Building target: CodeSample.elf''Invoking: ARM v8 Linux g++ linker'
aarch64-linux-gnu-g++ -o "CodeSample.elf" ./src/main.o stld1553.a stld1553drvapi_win32.a
stld1553.a(InterProcessSemaphore.o): In function `InterProcessSemaphore::Create()':
C:\SitalProjects\Linux_PCIe_Project\demo1\1553\Debug/../src/InterProcessSemaphore.cpp:91: undefined reference to `sem_open'
stld1553.a(InterProcessSemaphore.o): In function `InterProcessSemaphore::Open()':
C:\SitalProjects\Linux_PCIe_Project\demo1\1553\Debug/../src/InterProcessSemaphore.cpp:133: undefined reference to `sem_open'
stld1553.a(InterProcessSemaphore.o): In function `InterProcessSemaphore::Catch(unsignedint)':
C:\SitalProjects\Linux_PCIe_Project\demo1\1553\Debug/../src/InterProcessSemaphore.cpp:185: undefined reference to `sem_trywait'
C:\SitalProjects\Linux_PCIe_Project\demo1\1553\Debug/../src/InterProcessSemaphore.cpp:199: undefined reference to `sem_trywait'
stld1553.a(InterProcessSemaphore.o): In function `InterProcessSemaphore::Release()':
C:\SitalProjects\Linux_PCIe_Project\demo1\1553\Debug/../src/InterProcessSemaphore.cpp:229: undefined reference to `sem_post'
stld1553.a(InterProcessSemaphore.o): In function `InterProcessSemaphore::Close()':
C:\SitalProjects\Linux_PCIe_Project\demo1\1553\Debug/../src/InterProcessSemaphore.cpp:262: undefined reference to `sem_close'
C:\SitalProjects\Linux_PCIe_Project\demo1\1553\Debug/../src/InterProcessSemaphore.cpp:269: undefined reference to `sem_unlink'
stld1553drvapi_win32.a(SitalSDK.o): In function `_startInterruptPoll()':
C:\SitalProjects\Linux_PCIe_Project\demo1\API\Debug/../src/SitalSDK.cpp:2518: undefined reference to `pthread_create'
collect2.exe: error: ld returned 1 exit status
make: *** [makefile:50: CodeSample.elf] Error 1
17:49:30 Build Finished (took 508ms)
but 'undefined reference' is actually referenced when i clicked cntl+function !?
"undefined reference to <some symbol>" most likely means that you are using that symbol (e.g. function, class or global variable) in your code, but you did notlink the library where it is actually implemented!
Just because the declaration is available at compile-time, probably in a header file that you #include'd, does not mean that the implementation is available at link-time! You have to link the corresponding library file ;-)