Use versioned soname in shared library
tartina opened this issue · comments
Usually shared libraries have versioned soname which is incremented when a incompatible change is made.
The new kissfft shared lib doen't have this, it's soname is simply libkissfft.so.
When packaging for Fedora a versioned soname is mandatory, so I'm asking to add the version, like this in your Makefile::
SHARED := -Wl,-soname,libkissfft.so.0 -o libkissfft.so.0.1
The last number in the file name can be incremented independently when a new compatible version of the library is shipped.
Good idea! Are you working towards such a packaging?
datatype ?
I would tend towards making such a packaged version use kiss_fft_scalar=float as the default datatype.
Otherwise, trying to support multiple data types would require changing the function names, at least to retain the C interface.
For C++ kissfft.hh offers a header-only flexible option.
other tools?
I'd like to add optional features from the tools dir:kiss_fftr.* kiss_fftnd.* kiss_fftndr.*
Yes I'm the new maintainer of this package in Fedora. Till now it was a static only library built with float, double, int16 and int32 data types.
I'm trying to build the shared libraries to with these 4 data types.
Each data type library has a different naming, i.e.:
/usr/lib64/libkiss_fft_double.a
/usr/lib64/libkiss_fft_float.a
/usr/lib64/libkiss_fft_int16.a
/usr/lib64/libkiss_fft_int32.a
/usr/lib64/libkiss_fftnd_double.a
/usr/lib64/libkiss_fftnd_float.a
/usr/lib64/libkiss_fftnd_int16.a
/usr/lib64/libkiss_fftnd_int32.a
/usr/lib64/libkiss_fftndr_double.a
/usr/lib64/libkiss_fftndr_float.a
/usr/lib64/libkiss_fftndr_int16.a
/usr/lib64/libkiss_fftndr_int32.a
/usr/lib64/libkiss_fftr_double.a
/usr/lib64/libkiss_fftr_float.a
/usr/lib64/libkiss_fftr_int16.a
/usr/lib64/libkiss_fftr_int32.a
/usr/lib64/libkiss_kfc_double.a
/usr/lib64/libkiss_kfc_float.a
/usr/lib64/libkiss_kfc_int16.a
/usr/lib64/libkiss_kfc_int32.a
That naming convention works for linking, but what about developer packaging?
The interface names will be kiss_fft_alloc,kiss_fft, etc. regardless of the data type.
Can we make it less error prone?
Is modifying the function names the only way?
For static linking it's easy to use only one of the libraries, for dynamic linking it's more difficult, I think choosing only one data type would be acceptable for the shared library.
This way modifying the function names is not needed.
Hello, I've just opened #52 to improve the cmake build script a bit.
Adding versioning to cmake is just adding a VERSION property to the kissfft target.
To let developers choose what version they desire, cmake installs cmake config files + pkg-config files.
I've pasted an install prefix where all data types are installed with both shared and static libraries.
Prefix with shared/static x all datatypes
prefix
├── include
│ ├── kiss_fft.h
│ └── kissfft.hh
└── lib
├── cmake
│ └── kissfft
│ ├── kissfft-config.cmake
│ ├── kissfft-config-version.cmake
│ ├── kissfft-double-shared-targets.cmake
│ ├── kissfft-double-shared-targets-release.cmake
│ ├── kissfft-double-static-targets.cmake
│ ├── kissfft-double-static-targets-release.cmake
│ ├── kissfft-float-shared-targets.cmake
│ ├── kissfft-float-shared-targets-release.cmake
│ ├── kissfft-float-static-targets.cmake
│ ├── kissfft-float-static-targets-release.cmake
│ ├── kissfft-int16_t-shared-targets.cmake
│ ├── kissfft-int16_t-shared-targets-release.cmake
│ ├── kissfft-int16_t-static-targets.cmake
│ ├── kissfft-int16_t-static-targets-release.cmake
│ ├── kissfft-int32_t-shared-targets.cmake
│ ├── kissfft-int32_t-shared-targets-release.cmake
│ ├── kissfft-int32_t-static-targets.cmake
│ ├── kissfft-int32_t-static-targets-release.cmake
│ ├── kissfft-simd-shared-targets.cmake
│ ├── kissfft-simd-shared-targets-release.cmake
│ ├── kissfft-simd-static-targets.cmake
│ └── kissfft-simd-static-targets-release.cmake
├── libkissfft_double.a
├── libkissfft_double.so -> libkissfft_double.so.131
├── libkissfft_double.so.131
├── libkissfft_float.a
├── libkissfft_float.so -> libkissfft_float.so.131
├── libkissfft_float.so.131
├── libkissfft_int16_t.a
├── libkissfft_int16_t.so -> libkissfft_int16_t.so.131
├── libkissfft_int16_t.so.131
├── libkissfft_int32_t.a
├── libkissfft_int32_t.so -> libkissfft_int32_t.so.131
├── libkissfft_int32_t.so.131
├── libkissfft_simd.a
├── libkissfft_simd.so -> libkissfft_simd.so.131
├── libkissfft_simd.so.131
└── pkgconfig
├── kissfft-double.pc
├── kissfft-float.pc
├── kissfft-int16_t.pc
├── kissfft-int32_t.pc
└── kissfft-simd.pc
At first glance, this looks great. I will try to take a look at it this weekend to better understand it. I am somewhat ignorant of packaging and cmake so I'm a little uncertain how to evaluate it much more than a read-thru. Will you help me maintain it if it needs help in the future (or at least help point me/us in the right direction)?
Will you help me maintain it if it needs help in the future (or at least help point me/us in the right direction)?
Sure! Don't hesitate to tag me.
In my cmake pr, I only set the VERSION.
CMake also allows to set a SOVERSION.
I'm no specialist in versioning, but you might also want to define this in your Makefile.
I don't think the SOVERSION is bumped that often.
The version is currently extracted from the Makefile.
Are you planning to keep the Makefiles around?
(Let's move the cmake related conversation/questions to the cmake pr)