Re: [Libcdio-devel] [RFC/PATCH] add multi extent ISO9660 file support to libcdio

[Thomas Schmitt]

Hi,

Rocky Bernstein wrote:
> http://git.savannah.gnu.org/cgit/libcdio.git/tree/lib/driver/Makefile.am?id=16ff26506eedd748598f2beed4aa9825d04c1c9f#n30
> [...]
> Rule 4: interfaces have been added so we increment CURRENT and set REVISION
> to 0 and by
> Rule 5: itnerfaces have been added so we increment AGE

Yeah. That's about what i inherited with libburn too.


> So in total, the current C:R:A becomes C+1:0:A+1

Indeed. From
  libcdio_la_CURRENT = 18
  libcdio_la_REVISION = 0
  libcdio_la_AGE = 0
to
  libcdio_la_CURRENT = 19
  libcdio_la_REVISION = 0
  libcdio_la_AGE = 1

which are later used in line 172 with

  libcdio_la_MAJOR = $(shell expr $(libcdio_la_CURRENT) - $(libcdio_la_AGE))

a bit higher i read

  # compute MAJOR as CURENT - AGE; that is what is used within libtool
  # (at least on GNU/Linux systems) for the number in the SONAME.
  
So SONAME, the major lib*.so.N version number, does not change from
  18 - 0 = 18
to
  19 - 1 = 18


>  but then there's Pete's change which are in lib/iso9660.

My advise was to keep it API and ABI compatible within the limitations
of single-extent files by:
- Keeping and filling the deprecated struct members for API compatibility.
- Adding the new members to the end of the struct so that all old
  members do not move, which would spoil ABI compatibility.
Pete announced to works towards this goal.

With multi-extent files, the ill behavior of the old struct member API
might or might not change, but will stay ill. The advise towards
victims will then be to use the new multi-extent API.

-------------------------------------------------------------------------

In libburn, i increment CURRENT and AGE only once for a development cycle
and once for a release. So if i'd advise people to use the development
version, then i would now go from
   LT_CURRENT=105
   LT_AGE=101
to
   LT_CURRENT=106
   LT_AGE=102
and with the next release to
   LT_CURRENT=107
   LT_AGE=103
regardless whether 106:102 was actually used.
They all yield libburn.so.4.
Current release: libburn.so.4.101.0 (GNU/Linux)
                 libburn.so.4       (FreeBSD)
                 libburn.so.4.101   (OpenBSD, NetBSD)
Development:     libburn.so.4[.102[.0]]
Next release:    libburn.so.4[.103[.0]]

In libcdio it would now become
   libcdio_la_CURRENT = 19
   libcdio_la_AGE = 1
and at next release
   libcdio_la_CURRENT = 20
   libcdio_la_AGE = 2

I deem REVISION quite useless and always keep it at 0. 

All three parameters are handed to libtool with option -version-info.
Depending on the operating system, libtool will add one or more numbers
to the .so file name.
I had to tweak my local
  /usr/share/libtool/config/ltmain.sh
to get the intended SONAME as "major=.`expr $current - $age`" on the BSDs.
See "Building from Repositories on BSD [...]" in
  https://dev.lovelyhq.com/libburnia/web/wikis/Releases

Having a look into ./ltmain.sh of release tarball libcdio-0.94.tar.gz :
FreeBSD dynamic seems to be ok.
        freebsd-elf)
          func_arith $current - $age
          major=.$func_arith_result
But i find no such case for openbsd or netbsd. I dimly remember that the
behavior of my local libtool installation was undesirable.


Have a nice day :)

Thomas