SONAME: libCharLS.so.2
malaterre opened this issue · 6 comments
Dear CharLS maintainer,
I fail to understand what is going on with the SONAME/SOVERSION of CharLS. Here is what I see in CharLS 2.1.0:
% readelf -d libCharLS.so
[...]
0x000000000000000e (SONAME) Library soname: [libCharLS.so.2]
Here is what I see in CharLS 2.0.0:
% readelf -d /usr/lib/x86_64-linux-gnu/libCharLS.so
[...]
0x000000000000000e (SONAME) Library soname: [libCharLS.so.2]
However looking at the 2.1.0 exported symbols I find the following (Debian notation):
JpegLsDecode@Base 2.0.0+dfsg
JpegLsDecodeRect@Base 2.0.0+dfsg
JpegLsEncode@Base 2.0.0+dfsg
JpegLsReadHeader@Base 2.0.0+dfsg
_Z18JpegLsDecodeStream14ByteStreamInfoS_PK13JlsParameters@Base 2.1.0+dfsg
(arch-bits=32)_Z18JpegLsEncodeStream14ByteStreamInfoRjS_RK13JlsParameters@Base 2.1.0+dfsg
(arch-bits=64)_Z18JpegLsEncodeStream14ByteStreamInfoRmS_RK13JlsParameters@Base 2.1.0+dfsg
_Z22JpegLsReadHeaderStream14ByteStreamInfoP13JlsParameters@Base 2.1.0+dfsg
charls_get_error_message@Base 2.1.0+dfsg
charls_get_jpegls_category@Base 2.1.0+dfsg
charls_jpegls_encoder_create@Base 2.1.0+dfsg
charls_jpegls_encoder_destroy@Base 2.1.0+dfsg
charls_jpegls_encoder_encode_from_buffer@Base 2.1.0+dfsg
charls_jpegls_encoder_get_bytes_written@Base 2.1.0+dfsg
charls_jpegls_encoder_get_estimated_destination_size@Base 2.1.0+dfsg
charls_jpegls_encoder_set_color_transformation@Base 2.1.0+dfsg
charls_jpegls_encoder_set_destination_buffer@Base 2.1.0+dfsg
charls_jpegls_encoder_set_frame_info@Base 2.1.0+dfsg
charls_jpegls_encoder_set_interleave_mode@Base 2.1.0+dfsg
charls_jpegls_encoder_set_near_lossless@Base 2.1.0+dfsg
charls_jpegls_encoder_set_preset_coding_parameters@Base 2.1.0+dfsg
charls_jpegls_encoder_write_spiff_entry@Base 2.1.0+dfsg
charls_jpegls_encoder_write_spiff_header@Base 2.1.0+dfsg
charls_jpegls_encoder_write_standard_spiff_header@Base 2.1.0+dfsg
vs:
JpegLsDecode@Base 2.0.0+dfsg
JpegLsDecodeRect@Base 2.0.0+dfsg
JpegLsEncode@Base 2.0.0+dfsg
JpegLsReadHeader@Base 2.0.0+dfsg
JpegLsVerifyEncode@Base 2.0.0+dfsg
_Z18JpegLsDecodeStream14ByteStreamInfoS_PK13JlsParametersPc@Base 2.0.0+dfsg
(arch-bits=64)_Z18JpegLsEncodeStream14ByteStreamInfoRmS_RK13JlsParametersPc@Base 2.0.0+dfsg
(arch-bits=32)_Z18JpegLsEncodeStream14ByteStreamInfoRjS_RK13JlsParametersPc@Base 2.0.0+dfsg
_Z22JpegLsReadHeaderStream14ByteStreamInfoP13JlsParametersPc@Base 2.0.0+dfsg
This is acceptable behavior to add new symbols, but one cannot possibly remove existing ones without stating the change in the SOVERSION, namely:
JpegLsVerifyEncode@Base 2.0.0+dfsg
_Z18JpegLsDecodeStream14ByteStreamInfoS_PK13JlsParametersPc@Base 2.0.0+dfsg
(arch-bits=64)_Z18JpegLsEncodeStream14ByteStreamInfoRmS_RK13JlsParametersPc@Base 2.0.0+dfsg
(arch-bits=32)_Z18JpegLsEncodeStream14ByteStreamInfoRjS_RK13JlsParametersPc@Base 2.0.0+dfsg
_Z22JpegLsReadHeaderStream14ByteStreamInfoP13JlsParametersPc@Base 2.0.0+dfsg
References:
The public API functions:
JpegLsDecode@Base 2.0.0+dfsg
JpegLsDecodeRect@Base 2.0.0+dfsg
JpegLsEncode@Base 2.0.0+dfsg
JpegLsReadHeader@Base 2.0.0+dfsg
are present in both the 2.0.0 and 2.1.0 versions
The exported functions for the CharLS test application are for internal use only:
JpegLsVerifyEncode@Base 2.0.0+dfsg
_Z18JpegLsDecodeStream14ByteStreamInfoS_PK13JlsParametersPc@Base 2.0.0+dfsg
(arch-bits=64)_Z18JpegLsEncodeStream14ByteStreamInfoRmS_RK13JlsParametersPc@Base 2.0.0+dfsg
(arch-bits=32)_Z18JpegLsEncodeStream14ByteStreamInfoRjS_RK13JlsParametersPc@Base 2.0.0+dfsg
_Z22JpegLsReadHeaderStream14ByteStreamInfoP13JlsParametersPc@Base 2.0.0+dfsg
In 2.1 the functionality of JpegLsVerifyEncode has been moved to the test application. The other 3 internal functions are scheduled to be removed in the next update.
Could you confirm that options:
- CHARLS_BUILD_SAMPLES and
- CHARLS_BUILD_TESTS
are meant to be set to 'OFF' when distributing CharLS as binary packages on Linux distros (eg. Debian) ?
Good question. I would recommend setting these options to OFF for binary package distribution. I do not know if there is a guideline document somewhere that states how libraries like CharLS should be packaged for these kinds of distributions. CharLS is provided as source code only, other people create the packages, but I receive little feedback from that process.
For the C++ package manager vcpkg, these options are explicit turned off in the portfile and if you use CharLS as a CMake sub project. Vcpkg provides however guidelines how to optimal integrate a source code package.
Historically these options have been turned on by default for the CI build, but it could make more sense in the future to disable the options by default and enable them explicitly in the CI build.
Last question, could you confirm 2.1.0 release did not provision a mechanism to provide libCharLS.so on case sensitive system ? Currently I see only a libcharls.so being built.
For 2.1 the CMakeLists.txt files have been refactored to use modern CMake techniques. The library project name was changed to lowercase "charls", this to allign it with the typical Linux naming convention of shared libraries and the typical naming of the vcpkg package manager and to solve case sensitive problems for the long term.
I can see this might however be a breaking change from 2.0.0 to 2.1.0 for a binary package. It would be possible to add an option to the CMakeLists.txt script to switch back to the old output name.
Nevermind, using a bunch of symlinks did fix the build issue we had on Debian. Transition from 2.0 to 2.1 can be made on a binary basis, which is what I wanted.