Mail Archives: cygwin/2000/08/31/16:45:18
Chris Faylor wrote:
>
> On Thu, Aug 31, 2000 at 12:41:46PM -0700, Earnie Boyd wrote:
> >--- Chris Faylor <cgf AT cygnus DOT com> wrote:
> >>
> >> That means that the (so far hypothetical) DLL problems should be
> >> solvable by keeping the DLLs in the same directory as the executables.
> >>
> >
> >Great news! So my earlier suggestion stands to good effect. Unofficial Cygwin
> >packages should install in --prefix=/usr/local/packages.x.x.x. Official Cygwin
> >packages should install in --prefix=/usr. No need to prefix, suffix or munge
> >the names.
> >
> >Done,
>
> (Chris and Earnie shake hands and go about their business...)
>
> (Other people not quite so satisified...)
>
<g>
You're probably right about that. Since (for the most part) official
binaries are in /usr/bin ( == /bin) and official dll's are in /usr/bin (
== /bin), then prefix/suffix/munging of dll's is a non-issue (see point
#1 below).
However, this doesn't address the question of versioning the DLLs, for
source-incomaptible changes and ABI (object-code incompatible changes)
-- e.g. versioning would help alleviate problems introduced when the
libraries become incompatible in these ways. (I am not talking about
the core libs -- just the contrib libs like jpeg, tiff, readline... I
am also talking here only of problems that could crop up inside the
'cygwin' sandbox -- the versioning issue is orthogonal to the issue of
other 'platforms' or applications which use similarly named dlls)
So, I guess I still have two unanswered questions:
1) I want experimental proof of the above 'solution'. I think I'll go
build a native libz.dll and play some games unless someone beats me to
it.
2) DLL versioning. While I'm not keen on redoing all the dll-ized
packages that I've ported so far, IF it is deemed necessary I could see
versioning NEW releases, but ONLY when the library in question goes
through an API or ABI incompatible change.
----
For instance, right now libpng.dll is version 1.0.8. Next week, say,
the png folks release 1.0.9. Fine -- the updated cygwin version will
still be libpng.dll. Then, in a few months, the png folks release 2.0.0
(or 1.2.x). Ah -- that version will be libpng.2.0.dll or libpng.1.2.dll
(*) (but the import lib will be libpng.dll.a and will overwrite the old
import lib (**) ).
----
(*) Yes, I know it really should be libpng.3.0.dll (or libpng.2.2.dll)
since libpng-1.x.x is actually revision 2 of the API and libpng-2.x.x
will be version 3 of the API. It's just an example; don't get riled.
(**) Another controversial issue. Let's not discuss this one yet,
please.
Okay, restating my two remaining questions:
1) experimental proof that clever dll placement in the filesystem can
get us out of 'DLL hell'
2) should new libraries version their dll's when API/ABI changes?
--Chuck
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -