-L
specifies the library path, not a specific library. You probably want -L sdp/lib -l sdpAPI
to specify both the path and the library name.
Although it will try to prefix and postfix your library name with lib
and either .a
or .sl
(or similar).
So you may also need to rename your library to libsdpAPI.a
as per the gcc manpage:
-l xyz
The linker searches a standard list of directories for the library, which is actually a file named libxyz.a
.
Also keep in mind that the order of things in the command line matters. By doing $(CC) $(CFLAGS) $(INC_PATH) $(LIB_PATH) $(OBJECT_FILES) -o $(TARGET)
(libraries before objects), there are no unresolved symbols at the point where you list the library, so nothing will be brought in from that library.
Then, when you finally bring in the objects (with their unresolved symbols), they stay unresolved because there are no libraries listed after that.
You should usually do libraries after objects:
$(CC) $(CFLAGS) $(INC_PATH) $(OBJECT_FILES) $(LIB_PATH) -o $(TARGET)
to ensure all unresolved symbols are known before checking the libraries.
This won't catch all problems (such as co-dependent libraries which can be fixed using other means) but it will ensure all unresolved symbols in the object files are known about before looking at the libraries.
From the same section of the man page quoted above:
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o
searches library z
after file foo.o
but before bar.o
. If bar.o
refers to functions in z
, those functions may not be loaded.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…