Re: Building shared library for lzlib

[Antonio Diaz Diaz]

p.z.l wrote:
> > After looking at it I think that lzlib does not need the --soname mechanism;
> > it can simply create the shared library as liblz.so.1 instead of liblz.so.1.14.
>
> While I don't have strong opinion on --soname, calling liblz.so.1
> instead of liblz.so.1.15 is somewhat surprising and not well understood.

You may be right. In spite of lzlib not needing the --soname mechanism[1], 
distros are using the SONAME, and removing it from lzlib could break 
packaging or something else.

Therefore I have applied the attached patch to use --soname if supported and 
install liblz.so.$(pkgversion) as in version 1.14. Compilation now succeeds 
even if the linker does not accept --soname.

M S wrote:
> shared libraries on macOS have a suffix of .dylib.

I have a long tradition of not complicating the code just to support 
idiosyncratic file name extensions of non-free systems, like .exe in Windows 
and OS/2, .dll, etc. I have no idea of how macOS works, but if macOS allows 
the compilation of GNU libraries but does not understand the .so suffix, 
maybe installing the GNU linker can help, or you may ask Apple to add 
support for the .so suffix. Meanwhile, you may link liblz.dylib to liblz.so.

[1] Lzlib provides its own versioning mechanism through LZ_API_VERSION, and 
one of its goals is to keep backward compatibility with older versions of 
itself down to 1.0.

Best regards,
Antonio.

lzlib-soname.diff
Description: Text document