* liblockdep soname versioning @ 2014-04-01 12:56 Josh Boyer 2014-04-01 13:19 ` Sasha Levin 0 siblings, 1 reply; 6+ messages in thread From: Josh Boyer @ 2014-04-01 12:56 UTC (permalink / raw) To: Sasha Levin; +Cc: Linux-Kernel@Vger. Kernel. Org 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: liblockdep soname versioning 2014-04-01 12:56 liblockdep soname versioning Josh Boyer @ 2014-04-01 13:19 ` Sasha Levin 2014-04-01 13:28 ` Josh Boyer 0 siblings, 1 reply; 6+ messages in thread From: Sasha Levin @ 2014-04-01 13:19 UTC (permalink / raw) To: Josh Boyer; +Cc: Linux-Kernel@Vger. Kernel. Org 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? Thanks, Sasha ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: liblockdep soname versioning 2014-04-01 13:19 ` Sasha Levin @ 2014-04-01 13:28 ` Josh Boyer 2014-04-01 13:35 ` Sasha Levin 0 siblings, 1 reply; 6+ messages in thread From: Josh Boyer @ 2014-04-01 13:28 UTC (permalink / raw) To: Sasha Levin; +Cc: Linux-Kernel@Vger. Kernel. Org On Tue, Apr 1, 2014 at 9:19 AM, Sasha Levin <sasha.levin@oracle.com> 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. josh ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: liblockdep soname versioning 2014-04-01 13:28 ` Josh Boyer @ 2014-04-01 13:35 ` Sasha Levin 2014-04-01 15:33 ` Sasha Levin 0 siblings, 1 reply; 6+ messages in thread From: Sasha Levin @ 2014-04-01 13:35 UTC (permalink / raw) To: Josh Boyer; +Cc: Linux-Kernel@Vger. Kernel. Org On 04/01/2014 09:28 AM, Josh Boyer wrote: > On Tue, Apr 1, 2014 at 9:19 AM, Sasha Levin <sasha.levin@oracle.com> 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. Thanks, Sasha ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: liblockdep soname versioning 2014-04-01 13:35 ` Sasha Levin @ 2014-04-01 15:33 ` Sasha Levin 2014-04-01 15:34 ` Josh Boyer 0 siblings, 1 reply; 6+ messages in thread From: Sasha Levin @ 2014-04-01 15:33 UTC (permalink / raw) To: Josh Boyer; +Cc: Linux-Kernel@Vger. Kernel. Org 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 <sasha.levin@oracle.com> 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"] Thanks, Sasha ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: liblockdep soname versioning 2014-04-01 15:33 ` Sasha Levin @ 2014-04-01 15:34 ` Josh Boyer 0 siblings, 0 replies; 6+ messages in thread From: Josh Boyer @ 2014-04-01 15:34 UTC (permalink / raw) To: Sasha Levin; +Cc: Linux-Kernel@Vger. Kernel. Org On Tue, Apr 1, 2014 at 11:33 AM, Sasha Levin <sasha.levin@oracle.com> 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 <sasha.levin@oracle.com> >>> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-04-01 15:35 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-04-01 12:56 liblockdep soname versioning Josh Boyer 2014-04-01 13:19 ` Sasha Levin 2014-04-01 13:28 ` Josh Boyer 2014-04-01 13:35 ` Sasha Levin 2014-04-01 15:33 ` Sasha Levin 2014-04-01 15:34 ` Josh Boyer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox