This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

AW: ask for delivering cygwin 1.1.8 with kde 1.1.2


> > 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".
>
> <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
> 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
> >
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]