AW: ask for delivering cygwin 1.1.8 with kde 1.1.2
Wed Jun 13 23:59:00 GMT 2001
> > Robert Collins wrote:
> > >
> > > If libjpeg is breaking it's own ABI in a non-backward compatible
> > > without incrementing it's major version number, then I would be
> > > and talking to them with big sticks.
> > That is correct. The jpeg ABI changed between 6a and 6b, therefore
> > 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
> > 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
> > 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".
> <skip discussion on identifying libraries>
> > 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
> > > 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
> > 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
> > 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
to jpeglib6c, then kde will not run. :[
> > --Chuck
More information about the Cygwin-apps