From owner-freebsd-current@FreeBSD.ORG Mon Apr 27 08:18:12 2015 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C392F43D for ; Mon, 27 Apr 2015 08:18:12 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1AAAF10CC for ; Mon, 27 Apr 2015 08:18:11 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA11836 for ; Mon, 27 Apr 2015 11:25:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1YmeKH-000GDx-Mm for freebsd-current@FreeBSD.org; Mon, 27 Apr 2015 11:23:37 +0300 Message-ID: <553DF08A.9000007@FreeBSD.org> Date: Mon, 27 Apr 2015 11:17:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: FreeBSD Current Subject: backward dependencies on libzfs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 08:18:12 -0000 I am not sure what's the best list to discuss this issue, so let me raise it here. It seems that libzfs_core can not be used without also linking / loading libzfs: /lib/libzfs_core.so.2: Undefined symbol "zcmd_ioctl_compat" The same is true for libnvpair but for a different reason (and it looks like mea culpa): /lib/libnvpair.so.2: Undefined symbol "aok" Both dependencies seem to be backward, because: $ ldd /lib/libzfs.so.2 /lib/libzfs.so.2: libmd.so.6 => /lib/libmd.so.6 (0x801647000) libthr.so.3 => /lib/libthr.so.3 (0x801857000) libumem.so.2 => /lib/libumem.so.2 (0x801a7c000) libutil.so.9 => /lib/libutil.so.9 (0x801c7d000) libuutil.so.2 => /lib/libuutil.so.2 (0x801e8f000) libm.so.5 => /lib/libm.so.5 (0x802098000) *libnvpair.so.2 => /lib/libnvpair.so.2 (0x8022c1000)* libavl.so.2 => /lib/libavl.so.2 (0x8024d6000) libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x8026d8000) libgeom.so.5 => /lib/libgeom.so.5 (0x8028ff000) *libzfs_core.so.2 => /lib/libzfs_core.so.2 (0x802b04000)* libc.so.7 => /lib/libc.so.7 (0x80081f000) libsbuf.so.6 => /lib/libsbuf.so.6 (0x802d08000) So, there are circular dependencies between libzfs and the other library in both cases. It seems that those dependencies do not cause much, if any trouble, in practice, but they are not nice, because they are unexpected and they are not present on other OpenZFS platforms. -- Andriy Gapon