[haiku-commits] Re: r35324 - in haiku/trunk/src/libs/icu: . source/common source/data source/i18n source/stubdata
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 28 Jan 2010 15:06:41 +0100
On 2010-01-28 at 14:44:58 [+0100], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
>
> On 2010-01-28 at 13:04:24 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> >
> > On 2010-01-28 at 11:25:15 [+0100], Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
> > wrote:
> > AFAIK, the commonly used versioning scheme is the following:
> >
> > libfoo.so.1.2.3:
> > The actual library file. This is the third bug fix version since 1.2.0,
> > which
> > defines minor API version 1.2. It could as well be named libfoo.so.1.2
> > directly. Exists probably only for clarity. Otherwise the exact version
> > information would need to be specified somewhere else.
>
> Yup, I suppose the release version should be provided by the package, it's
> got
> nothing to do with the library interface.
Yeah, hopefully there aren't any configure scripts that determine the version
of the library by its name in case they want to check for a minimum minor API
version.
> > libfoo.so.1.2:
> > Symlink. 1.2 is the minor API version, i.e. all libfoo.so.1.x.y with x >=
> > 2
> > will be binary backwards compatible to this version.
>
> Ah, I obviously missed the notion of a minor API version. I find that
> notion a
> bit cumbersome, but I guess it makes sense to protect packages depending on
> a
> library from the need to update with minor adjustments to that lib. On the
> other hand, that opens the door to unresolved symbols if an app has been
> linked
> against libfoo.so.1.3 and then is being executed with libfoo.so.1.2.
Yep, but that's the package manager's job to deal with.
> > libfoo.so.1:
> > Symlink. 1 is the major API version defining the domain for binary
> > compatibility. That's also the soname of all 1.x.y libraries. Developers
> > usually link their apps/libraries against this one.
>
> Right, that's what I meant by API version. For the current ICU, this is 4.2
> (or
> 42 internally), i. e. that's incompatible with the upcoming version 4.4. So
> their major API naming scheme uses two digits :-\
> I suppose finding out the exact binary compatibility strategy for all those
> libs could become tedious, but I'm afraid there's no way around that. We
> should
> probably peek at OpenBSD, since they seem to have their own library API
> versioning, maybe we can lean on that.
Worth a look at least.
> > libfoo.so:
> > Symlink. Superfluous for libraries that significantly refactor/rename
> > stuff
> > between major version. For others, like libc.so, that have a largely
> > stable
> > API subset, that's what developers would link their stuff against.
> >
> > When I look at my linux lib dirs, I see that generally libfoo.so.1.2
> > seems to
> > be considered superfluous. Oftentimes libfoo.so is omitted. Moreover,
> > there's
> > no symlink chain (libfoo.so -> libfoo.so.1 -> libfoo.so.1.2 ->
> > libfoo.so.1.2.3) anymore. All symlinks point directly to libfoo.so.1.2.3.
> >
> > Back to your point: Omitting libfoo.so.1 wouldn't work, since that's the
> > library's soname. At least, if you want to allow programs linked against
> > 1.2
> > still to work with 1.3. libfoo.so can be omitted depending on the typical
> > (developer) use of the library. libfoo.so.1.2 is essentially useless,
> > unless
> > you don't want to have the full version information in the file name.
>
> Well, in your example, the API-version would be '1', so libfoo.so.1 would
> not
> be omitted, it would be the real lib and there'd be a link libfoo.so ->
> libfoo.so.1
That would work, yes.
> So which of all these (release, minor API, major API, basename) do we want
> in
> /system/lib and which of them in /boot/develop/lib/<arch>/?
> It is no problem to add support for all of them, but that would add quite
> some
> clutter.
OTOH it doesn't matter all that much either. It's not a directory in which
one usually does anything.
> I personally favour this setup:
>
> /system/lib only contains real libraries with their (major) API version as
> suffix, e.g. 'libfoo.so.1'. No basename links, at least not in the long run
> (though we keep them around for a while until all optional packages
> referring
> to libs via their basename have been updated).
>
> /boot/develop/lib/<arch> contains two links for public libraries: one with
> the
> major API suffix and one with the basename, both of which point to the
> corresponding lib in /system/lib. If we decide to provide separate ...-devel
> packages for development purposes, those would contain the headers and the
> links in /boot/develop/lib/<arch>. If not, those links would be provided by
> the
> standard package.
> Private libraries do not have any links in /boot/develop/lib/<arch>, so they
> are not available for development by default.
Sounds fine.
> Of course, that scheme would not allow support for backward compatibility
> between minor API versions.
Mmh, why is that?
CU, Ingo
Other related posts:
