Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751716AbaDAPfD (ORCPT ); Tue, 1 Apr 2014 11:35:03 -0400 Received: from mail-ob0-f179.google.com ([209.85.214.179]:57967 "EHLO mail-ob0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751635AbaDAPe7 (ORCPT ); Tue, 1 Apr 2014 11:34:59 -0400 MIME-Version: 1.0 In-Reply-To: <533ADC3A.6090800@oracle.com> References: <533ABCCB.4090502@oracle.com> <533AC08F.6020909@oracle.com> <533ADC3A.6090800@oracle.com> Date: Tue, 1 Apr 2014 11:34:59 -0400 X-Google-Sender-Auth: cz5jcQ3neiUz7UNa9e4RrPdRzOk Message-ID: Subject: Re: liblockdep soname versioning From: Josh Boyer To: Sasha Levin Cc: "Linux-Kernel@Vger. Kernel. Org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 1, 2014 at 11:33 AM, Sasha Levin wrote: > On 04/01/2014 09:35 AM, Sasha Levin wrote: >> >> On 04/01/2014 09:28 AM, Josh Boyer wrote: >>> >>> On Tue, Apr 1, 2014 at 9:19 AM, Sasha Levin >>> wrote: >>>> >>>> On 04/01/2014 08:56 AM, Josh Boyer wrote: >>>>> >>>>> >>>>> Hi Sasha, >>>>> >>>>> We've had a request [1] to package up liblockdep in Fedora. Looking >>>>> things over, I noticed the library isn't actually versioned at all and >>>>> instead just builds a plain .so file. That's likely fine during >>>>> development of it, but if distros are to ship it for broader use then >>>>> it would be a good idea to specify the soname and use a versioned .so. >>>>> >>>>> The makefile already has LIBLOCKDEP_VERSION defined. Would it be >>>>> possible to use this as the soname and version number? Then >>>>> liblockdep.so could be the normal symlink to the versioned .so >>>>> (liblockdep.so.0.0.1 in this case). >>>>> >>>>> Thanks. >>>>> >>>>> josh >>>>> >>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1082763 >>>>> >>>> >>>> Sure! I never expected it to live outside the kernel tree as a separate >>>> package, but I'm happy to accommodate for that. >>>> >>>> I think that I'll just match the version number with the kernel version >>>> since what mostly matters is what you have in kernel/lockdep.c, so for >>>> example, right now we'll have 'liblockdep.so.3.15.0'. Sounds good? >>> >>> >>> The only concern I would have is that it would require applications >>> linking to it to rebuild with every kernel release even if nothing >>> else changed. Maybe nothing changing is going to be rare enough that >>> in practice people will need to rebuild anyway. Either way, it's >>> better to be explicit rather than break users silently, so it sounds >>> good to me. >> >> >> I don't think we ever had a kernel version without changes to lockdep :) >> >> Since lockdep isn't an ABI either, no one promises me it'll work the same >> way between versions either, so I'm kinda happy about just forcing >> rebuilds. > > > Hi Josh, > > Could you please confirm that the below is what you'd expect it to be: > > sasha@lappy:~/linux/tools/lib/lockdep$ make > CC FPIC common.o > CC FPIC lockdep.o > CC FPIC preload.o > CC FPIC rbtree.o > BUILD STATIC LIB liblockdep.a > BUILD SHARED LIB liblockdep.so.3.14.0 > > sasha@lappy:~/linux/tools/lib/lockdep$ ls -al liblockdep.so > lrwxrwxrwx 1 sasha sasha 20 Apr 1 11:31 liblockdep.so -> > liblockdep.so.3.14.0 > > sasha@lappy:~/linux/tools/lib/lockdep$ readelf -d liblockdep.so | grep > SONAME > 0x000000000000000e (SONAME) Library soname: > ["liblockdep.so.3.14.0"] Yep, that does indeed look like what I would expect. Thanks for such a quick turn around! josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/