make generate-plist and lib.so.X.Y.Z

[Boris Samorodov]

On Tue, 24 May 2005 08:48:19 +0400 Boris Samorodov wrote:

> On Mon, 23 May 2005 16:39:53 -0700 Kris Kennaway wrote:

> > On Tue, May 24, 2005 at 02:37:29AM +0400, Boris Samorodov wrote:

> >  > $ cat work/.PLIST.mktmp 
> > > test/libtest.so.1.2.3
> > > test/libtest.so.1

> Shouldn't this be "test/libtest.so.1.2"?

> > > test/libtest.so.1
> > > test/libtest.so
> > > -----
> > > 
> > > If it's a feature, then where I can get an info on it? Or is it a bug?

> > What are you asking about, exactly?

> > Kris

To be more strict. The developers-handbook/policies-shlib.html says:
-----
Note: ld.so will always use the highest “minor” revision. For
instance, it will use libc.so.2.2 in preference to libc.so.2.0, even
if the program was initially linked with libc.so.2.0.

In addition, our ELF dynamic linker does not handle minor version
numbers at all. However, one should still specify a major and minor
version number as our Makefiles “do the right thing” based on the type
of system.
-----

It is about linking process. Nothing said about installation. But at
ports/Mk/bsd.port.mk at the generate-plist: label we have:
-----
.if (${PORTOBJFORMAT} == "aout")
        @${SED} -e 's,\(/lib.*\.so\.[0-9]*\)$$,\1.0,' ${TMPPLIST} > ${TMPPLIST}.
tmp
.else
        @${SED} -e 's,\(/lib.*\.so\.[0-9]*\)\.[0-9]*$$,\1,' ${TMPPLIST} > ${TMPP
LIST}.tmp
.endif
-----

Isn't it preventing shlib.{major}.{minor} to be registered as
installed one?


-- 
bsam