[nas] NAS 1.8 (stable) is available

[James Lee]

On 04/06/06, 19:48:01, Jon Trulson <jon at radscan.com> wrote regarding Re:
[nas] NAS 1.8 (stable) is available:

> > I notice the SONAME has changed to libaudio.so.2.4. The version has
> > gone from 2.3 to 2.4, I don't mean the file name but the SONAME in
> > the elf headers.  There are no changes to the header files, has the
> > API changed?  Why the change the SONAME?  Why add the version to the
> > SONAME?  What should the SONAME be?
> >

>          I've always updated the SONAME whenever the library is changed
>          in any significant way (like the Alibint and the connection
>          logic in this version).  If the API itself were to change in an
>          incompatible way, then the major number would be incremented,
>          otherwise I just increment the minor...

>          However, after doing a little googling on the subject, the
>          general consensus seems to be to only change the SONAME when
>          an actual API/ABI change is made that would make the library
>          incompatible with previous verisons.  This seems sensible, and
>          will be the practice I follow in the future.

>          I need to figure out the SO 'release version' number stuff
>          though so it is easy to tell what library is what.  Even
>          though no ABI/API change may occur, the behavior of the
>          library could be altered by future updates/bug fixes - I'd
>          like some way of knowing exactly which '2.4' library I'm
>          dealing with.

You can still change the library number, just as you have to 2.4 but
leave the the minor rev increment off the SONAME in the elf headers.

The problem with an SONAME with the minor version in the elf headers
is that programs linked to libaudio.so will look for a file with that
specific version.  When -laudio is used it finds the real file by
link to libaudio.so.2.4 but your SONAME means it always gets linked to
the versioned file.  On update that file changes so we have to provide
a .2.3 so as not to break linkage with existing programs and further
those program won't use the new NAS until they are relinked.

Example.

The old libaudio.so.2.3:
$ dump -Lv libaudio.so | grep SONAME
[1]     SONAME          libaudio.so.2.3


The new one:
$ dump -Lv libaudio.so | grep SONAME
[1]     SONAME          libaudio.so.2.4


Now inspect a client:
$ dump -Lv libvclplug_gen680si.so | grep libaudio
[24]    NEEDED          libaudio.so.2.3

Note it looks for libaudio.so.2.3 and not libaudio.so, hence the new
NAS breaks the linkage.


I suggest that as the major version is 2 there could be a libaudio.so.2
symbolic link and that could be the SONAME.  The file can retain the
minor version as it does now.





How to do with imake.... oooerrr.... This is doing it, the definition of
SharedLibraryTarget:

Concat(lib,libname.so.rev):  solist     $(MAPFILE)
      @@\
        $(RM) $@~
@@\
        $(CCENVSETUP) $(LD) -o $@~ $(SHLIBLDFLAGS) -h $@ solist
$(REQUIREDLIBS)
@@\


The "-h $@" sets the soname to that of the target, ie, the file with
full rev.  There doesn't seem to be a major/minor split option.


I'd let imake run then [s]edit the Makefiles before build!





James.