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 _______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
