On 18.07.2023 09:09, Raj, Rahul via discuss wrote:
[AMD Official Use Only - General]
I am building MariaDB from source code and have queries on linking of compression algorithm.
Before building the source code of MariaDB, I am exporting the path for SNAPPY or LZMA or the algorithm which is currently it supports.
How do you do that?
When I checked the lib/plugin folder it has generated, provider_lzma.so or provider_snappy.so files and when I did ldd on that .so file, it has given the path from where it is fetching the liblzma.so.1 or libsnappy.so.1 file.
So that works. cmake uses system search paths to locate include files and libraries by default.
1. The path which ldd shows for provider_lzma.so or provider_snappy.so is taking form default path, and it is not from the path which I am exporting the library and bin path – could you please explain me the correct steps.
There are typically two cmake options for each compression method. For example for snappy: SNAPPY_INCLUDE_DIRS SNAPPY_LIBRARIES if you want cmake to use a specific implementation of snappy, you must specify those on the cmake command line: cmake ... -DSNAPPY_INCLUDE_DIRS="/foo/include" -DSNAPPY_LIBRARIES="/foo/lib" ccmake lists all the possible cmake options in advanced mode.
2. Is there any way or any Flag we can set to switch between different compression method during build time itself, and in which log we can check it has linked properly.
cmake spits out messages to stdout, i.e. on my system for snappy: -- Found Snappy: /usr/lib/x86_64-linux-gnu/libsnappy.so and at the end of configuring cmake also lists all found packages on stderr. The compressions libraries are in the optional section: -- The following OPTIONAL packages have been found: * BZip2 * LZ4 (required version >= 1.6) * LZO * Snappy You can parse that output. And/or use ldd on the plugins in $PLUGINDIR
3. How to benchmark the linked compression method and how we can see it is using the linked compression method from the custom path of .so files.
Use any benchmark you see fit. I.e. you can try to reproduce Perconas published numbers. They have published a lot on compression. Most benchmarks do poorly for compression since they use generated data (i.e. random strings - not compressible). Benchmarks thus fail to make the real world behavior visible. For that you need real world data. HTH, XL