G++ Searches /Lib/../Lib/, Then /Lib/

LD_LIBRARY_PATH vs LIBRARY_PATH

LIBRARY_PATH is used by gcc before compilation to search directories containing static and shared libraries that need to be linked to your program.

LD_LIBRARY_PATH is used by your program to search directories containing shared libraries after it has been successfully compiled and linked.

EDIT:
As pointed below, your libraries can be static or shared. If it is static then the code is copied over into your program and you don't need to search for the library after your program is compiled and linked. If your library is shared then it needs to be dynamically linked to your program and that's when LD_LIBRARY_PATH comes into play.

gcc and g++ library search paths

This would indicate that the installation of gcc isn't complete. You may need to install (e.g. sudo yum install libstdc++-devel glibc-devel). This will work assuming that the gcc was actually installed using the standard packages from redhat. You may of course need some other libraries too, depending on what you are actually developing.

Of course, the RIGHT thing to do is to complain to IT, but I suspect that if you want some work done today (if your IT is anything like the ones I've worked with), you're better off doing it yourself, if you at all can do that. (Oh, and most of the time, in my experience, they have no idea how to solve the problem, so give them the above information!).

how to import opencv lib into other lib using g++

I think what you want to do is get (e.g.) libopencv_imgproc.so,
located in /usr/local/lib, to be linked with your shared library libMat.so.

The way you are trying to do this in your makefile is by "linking"
libopencv_imgproc.so with the object file libMat.o by the recipe:

libMat.o : Mat2Image.cpp Mat2Image.h
    g++ $(CFLAGS) -fPIC -I/usr/lib/jvm/jdk1.8.0_111/include \
        -I/usr/lib/jvm/jdk1.8.0_111/include/linux -c $< -o $@ \
        -L/usr/local/lib

You think that -L/usr/local/lib at the end will in some way let the linker
know you want to link libopencv_imgproc.so and do so.

That won't work for more than one reason:

-L/usr/local/lib will just tell the linker that /usr/local/lib is
a directory where you want it search for libraries that you ask it to
link. It doesn't ask it to link any libraries from there, and if you
don't tell it to, it won't. To tell the linker
to search for libraries in /usr/local/lib and ask it to link
libopencv_imgproc.so you would use:

`-L/usr/local/lib -lopencv_imgproc

But you don't need to tell it to search for libraries in /usr/local/lib,
because that is one of the directories the linker searches for libraries
by default. So -lopencv_imgproc is all you would need.

But more important than that,

g++ $(CFLAGS) -fPIC -I/usr/lib/jvm/jdk1.8.0_111/include \
            -I/usr/lib/jvm/jdk1.8.0_111/include/linux -c $< -o $@ \
            -L/usr/local/lib 

is the command that simply compiles libMat.o from Mat2Image.cpp. It
doesn't do any linkage. It is not possible and does not make sense to "link"
anything with an object file. So adding any linkage options to your
compile command is pointless. The compiler will ignore them. This command is
effectively no different from:

g++ $(CFLAGS) -fPIC -I/usr/lib/jvm/jdk1.8.0_111/include \
            -I/usr/lib/jvm/jdk1.8.0_111/include/linux -c $< -o $@

and that's what it should be.

The recipe that does your linkage is:

libMat.so : libMat.o
    g++ $(CFLAGS) -W -shared -o $@ $<

So this is where you have to tell the linker that you want libopencv_imgproc.so
to be linked:

libMat.so : libMat.o
    g++ $(CFLAGS) -W -shared -o $@ $< -lopencv_imgproc

With this, libMat.so will be linked containing libMat.o and a runtime
dependency on the shared library libopencv_imgproc.so - that is, an
instruction to the runtime loader that it must load libopencv_imgproc.so
into the same process when it loads libMat.so.

Your makefile has various other faults but what I've said is enough to
explain and fix the particular problem I think you're asking about. You
can learn how to write a better makefile, if you want, by searching for tutorials
and ariticles about GNU Make and studying the documentation

I'll just point out one other fault that is serious. Your recipe:

clean:
    rm -f Mat2Image.h libMat.o libMat.so

is going to delete the header file Mat2Image.h when you run
make clean. That header file is one of your original source files. It
isn't generated by this makefile - like libMat.o and libMat.so - unless
you've ommitted some bits of the real makefile. So
if you delete it you'll have to recover it from you source-control system; and
if its not under a source-control system, you'll have to rewrite it. So
I think you just want:

clean:
    rm -f libMat.o libMat.so

How does g++/gcc determine which library to link having more than 1 version to choose from?

GCC does not choose, per se. While GCC (actually ld) will find and examine dynamic libraries when linking (by its own path search order), it merely adds a DT_NEEDED entry for the library's SONAME. Take a look at the DYNAMIC section with readelf.

At runtime, ld.so chooses which library to link against. The particular library which ld.so selects is determined by its configured path search order. See the man page for ld.so.

---

Related Topics