This is the mail archive of the cygwin@sources.redhat.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]

Re: DLL naming conventions


Chris Faylor wrote:
> 
> On Thu, Aug 31, 2000 at 12:41:46PM -0700, Earnie Boyd wrote:
> >--- Chris Faylor <cgf@cygnus.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@sourceware.cygnus.com


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