Date: Thu, 27 Aug 1998 09:32:09 +0000 From: Mike Smith <mike@smith.net.au> To: Dave Dittrich <dittrich@cac.washington.edu> Cc: Satoshi Asami <asami@FreeBSD.ORG>, mike@smith.net.au, billf@chc-chimes.com, ports@openbsd.org, ports@FreeBSD.ORG Subject: Re: Shared libraries in packages Message-ID: <199808270932.JAA03906@word.smith.net.au> In-Reply-To: Your message of "Thu, 27 Aug 1998 08:40:05 MST." <Pine.ULT.4.02.9808270829270.994-100000@red5.cac.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, 27 Aug 1998, Satoshi Asami wrote: > > > * We change the major and minor versions in accordance with a.out naming > > * policy, not simply to match the version number of the particular > > * package (which normally doesn't). > > > > Yes. See the handbook's "policy" section for more detail. > > Let me remind you that I use OpenBSD and was getting ports from the > openbsd.com web page. Are you talking about a FreeBSD policy? I don't recall > seeing it on the page I was using, although I could be mistaken. If you were complaining about running a FreeBSD binary, you may need to be aware of FreeBSD policy. > > * In this case, it means that the library has undergone one non-backwards > > * -compatible change (1.x to 2.1) and one backwards-compatible change > > * (2.1 to 2.2). > > > > Two. The first 2.X version is 2.0. :) > > > > Actually, I believe we bumped all libraries to 2.0 when we released > > FreeBSD 2.0R, which was based on a different codebase from 1.*. > > This seems to entirely defeat the purpose of shared libraries and shared > ports. It certainly doesn't defeat the point of shared libraries; in fact it specifically *is* the point of having version numbers in shared libraries. Shared ports are normally only useful at the source level. There's no guarantee that the FreeBSD emulation in OpenBSD will be adequate at any given point in time, and given that you have the source to everything, it would make more sense to compile native. > If the OpenBSD community does not use this same scheme (which I don't > think is really wise, considering it breaks all versioning consistant with the > original source authors' naming conventions. (If they upgrade libpcap today > to 0.5, does that mean you have to then go to 2.3? Why not use a convention > like 0.4-2.3 or 0.4.2.3 to stay closer to the original?) Shared libraries have a major number and a minor number. The major number is incremented when a change is made to the library which renders it unsuitable to be linked against an executable that was linked with the previous version. The minor number is incremented when any other change is made which affects the ABI/API in a compatible fashion. Shared library versioning is for the benefit of the linker, not the user. Attempting to embed the actual release number of the library in the version number is not useful. > Regardless, I think this means that you should not put *any* non-static > binaries on the OpenBSD site (that are created on FreeBSD systems) or at least > provide source for all ported products (as I can't recompile libpcap until I > find the source somewhere else besides the OpenBSD site - I'll start sending > email to the people who created the ports to build my own.) You don't need to recompile libpcap, you need to recompile the *application* that's complaining about it. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808270932.JAA03906>