build: choose the libraries shipped in third-party (by default) or the system libraries

[zhanghaohit]

If users compile in its own physical machines rather than the provided docker environment, there may be some linking issues.

Expected Behavior

use the static libraries located in .deps/usr/ first, then system dynamic libraries

Current Behavior

If the system has already installed some libraries, it will link these libraries from system locations rather than the static libraries in the project-specific locations (i.e., .deps/usr).

e.g., brpc protobuf glog gflags unwind ssl crypto leveldb z snappy and others

Possible Solution

use find_library or find_package to look for the libraries in the project library location (.deps/usr) first, then other system locations.

Steps to Reproduce

1. if the system has already installed the dependent libraries which do not meet the requirements of OpenMLDB, the complication will fail.

Context (Environment)

custom os environment (not provided docker environment)

Detailed Description

Possible Implementation

[aceforeverd]

It mainly rely on CMAKE_PREFIX_PATH currently, not sure what happen in other custom OS but It compiles on my Debian

[zhanghaohit]

It mainly rely on CMAKE_PREFIX_PATH currently, not sure what happen in other custom OS but It compiles on my Debian

If we simply specify -lxx, it will first try to find its dynamic version first. That is, it will try to find libxx.so in either CMAKE_PREFIX_PATH or system lib path. If cannot find, it will then try to find libxx.a.

So if the system lib path has libxx.so, it will use it rather than libxx.a in CMAKE_PREFIX_PATH, which may cause some problems if the system-wide libxx.so is not consistent with our required versions.

I think the simple solution is that we have to use find_library or find_package to find the lib xx, which will search both static lib libxx.a and dynamic lib libxx.so in CMAKE_PREFIX_PATH first, and then system lib path. This is the expected behavior.

We have already fix it for boost and icu libraries in #1119. Other libs should be fixed in a similar way.

[zhanghaohit]

This issue related to issue #1118

[tobegit3hub]

We have compile with latest code and dynamic link boost in Python SDK. The libraries of openssl and libncurses should be handled as well.

[aceforeverd]

Is this issue resolved ? @zhanghaohit

[zhanghaohit]

Is this issue resolved ? @zhanghaohit

It seems that there are still some remaining libraries, e.g., tcmalloc, unwind, etc. that are not updated.