[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] [RFC/PATCH] add multi extent ISO9660 file support to libcdio
Date: Thu, 14 Jun 2018 00:44:17 +0200


Rocky Bernstein wrote:
> [...]
> 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
  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
  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
and with the next release to
regardless whether 106:102 was actually used.
They all yield
Current release: (GNU/Linux)
          (OpenBSD, NetBSD)
Next release:[.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
to get the intended SONAME as "major=.`expr $current - $age`" on the BSDs.
See "Building from Repositories on BSD [...]" in

Having a look into ./ of release tarball libcdio-0.94.tar.gz :
FreeBSD dynamic seems to be ok.
          func_arith $current - $age
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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]