Let's be clear. In most cases these days it is the compiler [clang or clang++] that is the "linker driver". ld is the link editor or linker.
-l (lower case L) specifies the name of a library to link. The convention is that library files start with "lib" which is implicit with the -l option, and they end with .so (dynamic libraries) or .a (static libraries). So "-lQtGui" will typically mean "libQtGui.so".
-L specifies a link editor search path, where the link editor will search for libraries.
-I (capital i) tells the compiler pre-processor where to search for header (.h or similar) files for the pre-processor to include. Not much to do with linking.
There are a couple more things that affect linking. If you have both static and dynamic libraries in the same directory, the link editor will choose the dynamic one by default. You can override that with -Bstatic. So you might have something like
LDFLAGS = -L /path/to/my/libs -lpkg1 -Bstatic -lpkg2 -Bdynamic -lpkg3
which will link with libpkg1.so libpkg2.a and libpkg3.so even if both .so and .a versions of all 3 libs exist.
Getting the link editor to work is the largest part of the work. But you still need to contend with the link loader. With static libraries, once the link editor is done it's all over. Not so with dynamic libraries. When the executable starts the link loader (ld.so) has to figure out where all the dependent dynamic libraries are. The rules for this are fairly complicated, but roughly the order is RPATH, LD_LIBRARY_PATH, RUNPATH, some system search path like crle, "well known locations" like /usr/lib.
I recommend linking with RPATH.
LDFLAGS = -Wl,-rpath,/path/to/my/libs
If BUILDDDIR != INSTALLDIR then you can make this relative with $ORIGIN
LDFLAGS = -Wl,-rpath,$$ORIGIN/../lib
(getting the dollars right can be a pain as make and the shell consider single dollars as env vars)
I recommend LD_LIBRARY_PATH if you really like unexpected spectacular crashes and forcing every application to be launched with a script that sets LD_LIBRARY_PATH.
