ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2001/06/13/12:30:19

Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3B277ED2.BA40EBD1@ece.gatech.edu>
Date: Wed, 13 Jun 2001 10:55:14 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: Ralf Habacker <Ralf DOT Habacker AT saght DOT tessag DOT com>,
Cygwin-Apps <cygwin-apps AT cygwin DOT com>,
Suhaib Siddiqi <ssiddiqi AT inspirepharm DOT com>,
Alan Hourihane <alanh AT fairlite DOT demon DOT co DOT uk>
Subject: Re: ask for delivering cygwin 1.1.8 with kde 1.1.2
References: <000901c0f3f4$413954e0$6e032bb7 AT BRAMSCHE> <011801c0f3f8$7f2034f0$0200a8c0 AT lifelesswks>

Robert Collins wrote:
> If libjpeg is breaking it's own ABI in a non-backward compatible fashion
> without incrementing it's major version number, then I would be going
> and talking to them with big sticks.

That is correct.  The jpeg ABI changed between 6a and 6b, therefore the
6b dll uses "cygjpeg6b.dll" as its versioned name.  Ditto readline
between 4.1 and 4.2 -- the ABI (and API) changed; since I wasn't
expecting *that*, the 4.1 readline dll was "cygreadline4.dll" but the
4.2 dll was "cygreadline4.2.dll".  However, the cygwin readline 4.2 is
still marked "test" -- it's not too late to change the name to
"cygreadline4-2.dll" if you think that's a better scheme.  I do NOT
believe that dll names should include patch numbers or release numbers. 
Preferably only major numbers -- and minor numbers if necessary due to
bonehead ABI changes...

IMO, libtool (or KDE) shouldn't try to parse dll names for versioning
information.  Instead, it should build a tiny app (just link: 
-lreadline -- without a version # -- always works); this app should just
return the version string *as the library stores is*.  Almost all
libraries have some sort of getVersion function.

Of course, jpeg is a bad example, since it doesn't.  For jpeg, you'd
have to do:
#include <stdio.h>
#include <jpeglib.h>
which really only checks the header version ("62" == 6b) since
JPEG_LIB_VERSION is just a #define in jpeglib.h

For readline, you'd do
#include <stdio.h>
#include <readline/readline.h>
which returns "4.2" -- and really represents the dll version since
rl_library_version is a const char* DATA export from the dll.

> >From what you are saying it sounds like a program llinked to libjpeg
> 6.1.0 won't run with libjpeg 6.1.1. That's pretty unusual for
> libraries - can the version checking be made more sane? Or is that
> because of the current beta state of libjpeg?

See above.  Jpeg isn't really beta, in the sense that it will eventually
be made "stable".  6b is about two years old.  Tom Lane has mumbled
about releasing 6c "eventually" -- but don't hold your breath.  "6c"
will NOT contain any of the jpeg2000 stuff, even if 6c is ever actually

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019