I built my shared library(I use a lib calculating the fibonacci number for example) myself and want to use it in my another c++ project built by CMake
L
You may want to look into CMake's RPATH handling settings
This quote in particular seems relevant to your predicament:
By default if you don't change any RPATH related settings, CMake will link the executables and shared libraries with full RPATH to all used libraries in the build tree. When installing, it will clear the RPATH of these targets so they are installed with an empty RPATH.
You can set the RPATH that is set for installed binaries using the CMAKE_INSTALL_RPATH
variable, for example:
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
and you can also disable the RPATH stripping during installation:
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
I just want to answer question 1. The why this is done. Alex already posted a solution how to change this behaviour.
The reason is that when you build it you really want to use the libraries the build script saw on your machine. If you build a whole stack of libraries for your app you want no mistake that they aren't picked by the library. Therefore it makes sense to use the full rpath to the library. Also you never move your application around between compilation and when it's debugged and run.
But when installed the usual case in the unix world was to use the shared /usr/lib and /usr/local/lib directories. They are usually picked up (unless LD_LIBRARY_PATH is used) and thats normally what you want.
As you see by my wording, all this is a mess because it includes so many implicit decisions how you organize your build and your deployment. It is one of the reasons why the term 'DLL hell' once only popular on Windows moved over to Unix when it became more widely used. There is no technical solution because its not a technical problem (that part is solved). Its an organizational problem and CMake has to decide about the one flavour it supports on a platform by default. And IMHO they have choosen wisely.