[cmake-developers] New no-soname-option topic for e.g. Android

[Vadim Zhukov]

28.05.2014 18:57 пользователь "Nils Gladitz" <nilsgladitz at gmail.com>
написал:
>
> On 28.05.2014 16:14, Ben Boeckel wrote:
>>
>> On Wed, May 28, 2014 at 10:39:22 +0200, Nils Gladitz wrote:
>>>
>>> As discussed here
http://www.cmake.org/pipermail/cmake/2014-May/057657.html
>>> I proposed a minor modification in CMake that would allow shared library
>>> targets to always be linked by -l/-L options rather than full pathname
>>> on platforms which do not support SONAMEs.
>>>
>>> I remember there being discussions on adding support for Android as a
>>> platform.
>>> If anyone is still working on it this topic might already be superfluous
>>> so I haven't merged it yet.
>>
>> I have some Android work at home and I remember setting up Android to
>> *have* a SONAME so that things worked properly (there were weird errors
>> otherwise). I'll have to look into where things broke without it, but I
>> won't get a chance until Tuesday.
>>
>> --Ben
>
>
> I assumed that because people kept removing the soname options for their
Android toolchains that SONAMEs aren't supported at all.
>
> It however looks like they just can't have versioned names.
> Perhaps ignoring the VERSION/SOVERSION properties would suffice since the
default SONAME should work which would make this topic superfluous at least
for android.
> It sounds like you probably already have all of that covered.
>
> Would this be the same in the OpenBSD case perhaps? Do they have/want
SONAMEs but don't want them versioned?
> If this is the case this topic as-is can probably be removed again.

We in OpenBSD fully support SONAME itself. But since we always version
shared library file names as libfoo.so.X.Y, SONAME creates more problems
than solves (actually, it doesn't solve a one for us). So we prefer to drop
SONAME entirely, and do so consistently in our Ports tree, which has full
support for building CMake-based software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140528/bfe06ed7/attachment-0002.html>