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: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com From: "Ralf Habacker" To: "Cygwin-Apps" Cc: "Robert Collins" , "Suhaib Siddiqi" , "Alan Hourihane" Subject: AW: ask for delivering cygwin 1.1.8 with kde 1.1.2 Date: Thu, 14 Jun 2001 09:02:03 +0200 Message-ID: <005701c0f49f$ea4bfdc0$6e032bb7@BRAMSCHE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <022f01c0f466$7bbe6250$0200a8c0@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... > > I Agree that dll's should only have major numbers (".."). Libtool > numbers by ABI and API, so for libtool, we should be able to minimise > the number of concurrent .dll's needed. I _think_ the major number > always changes on backwards-compatible-breakages (ABI or API). > > > 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. > > Libtool isn't ralf's problem - it's the code from libjpeg that's causing > grief. Libtool doesn't care or check version numbers. In fact in libtool > you cannot specify "I need version foo", you can only specify "this > library I am making is compatible to the last 3 revisions, has had 45 > trivial changes, and is on it's 3 rewrite". > > > > 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 > > released. > > Given the above, that the library file name changed with the ABI, > libjpeg should not be an issue, if ralf links against the correct > library name - which will be resolved by the import library at link > time. So... what's happening? > But what about when kde for example is installed and uses jpeglib6b and the user updates to jpeglib6c, then kde will not run. :[ > Rob > > > --Chuck > > > >