svn commit: r284107 - head/sys/cddl/compat/opensolaris/sys

[Andriy Gapon]

On 09/06/2015 16:41, Jan Beich wrote:
> Andriy Gapon <avg at FreeBSD.org> writes:
> 
>> On 09/06/2015 13:31, Jan Beich wrote:
>>
>>> Andriy Gapon <avg at FreeBSD.org> writes:
>>>
>>>> Author: avg Date: Sun Jun  7 08:54:25 2015 New Revision: 284107 URL:
>>>> https://svnweb.freebsd.org/changeset/base/284107
>>>>
>>>> Log: compat nvpair.h: make sure that the names are mangled only for
>>>> kernel
>>>>
>>>> Currently there is no good reason to mangle the userland API. The change
>>>> was introduced in eac1d566b46edef765754203bef22c75c1699966, r279437.
>>>> Also see https://reviews.freebsd.org/D1881.
>>>
>>> Can you bump __FreeBSD_version? At least sysutils/geomWatch requires it.
>>>
>>> https://svnweb.freebsd.org/changeset/ports/388906
>>
>> There should have been a bug report and an src fix instead of (parts of)
>> https://svnweb.freebsd.org/ports?view=revision&revision=386870
> 
> Good point. However, opensolaris libs have unclear ABI guarantees.

Indeed.

> Their
> API is not exposed but the libs aren't marked PRIVATELIB. Some symbols
> are removed on updates *without* corresponding SHLIB_MAJOR bumps.
> libnvpair is mostly unchanged between 8.4R and 11.0C, though.

I think that we should treat ABI breakages for ZFS-related libs same as for
other libs.  Symbol versioning could be a hassle, but at least a library version
bump is warranted.

>   # shouldn't be possible without libzfs.so.2 in libmap.conf
>   /poudriere/jails/84amd64/sbin/zfs: Undefined symbol "zpool_set_history_str"
> 
>> I wonder why the libnvpair ABI breakage was silently accepted but the ABI fix
>> requires some special magic...
> 
> I'll probably back out ports at 386870 and ports at 388906 after a while.
> libnvpair with bogus ABI existed on 11.0C for 3 months, enough to end up
> in the binary snapshots a few times.

In either case please let me know if the __FreeBSD_version bump would be of help
to you, I certainly can do it.

-- 
Andriy Gapon