Re: DLL naming conventions

[michael-ring at t-online dot de (Michael Ring)]

>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'

I think that is impossible. Take the following user scenarios:

User1 is happy with cygwin as as 'linux light' on his pc. He uses
cygwin only in it's own environment (means he first starts bash with
the cygwin-icon and then works from within bash), his path will only
include applications that reside inside the cygwin-tree. 

No (real) dll-hell here.

User2 is a NT-User who has found out that the standard tools that come
with Windows/NT are not powerfull enough to assist him in doing his
daily job. This user will have the cygwin directories somewhere in his
path. And here the fun begins. 

It is correct that applications always use dll's that come from the
current directory or from the directory that the application loaded
from. But according to Earnie's ideas contributed software ends up in
/usr/local/somewhere.

When an application starts from /usr/local it takes dll's first from
the app's dir, then from current dir, the path is searched. Here we
have dll-hell, because noone can predict how the path of this user
will look like. It is now possible that references to dll's are found
in gimp, in cygwin's /usr/bin or anywhere else. 

I can imagine that user2 can be found often, at least a lot of
person's i know use cygwin in that manner. They do not really care for
the inner beauty of cygwin (which imho is there ;-) ) they use cygwin
because it has well working grep, awk, sed & vi inside. (Those guys
are the only reason I can understand why text-mode is still inside of
cygwin)

The only solution to this dll-hell would be to put all cygwin-apps in
one directory together with all dll's provided by cygwin & contrib. A
task that i personally would not prefer exspecially if you think about
X11R6 which by default ends up in /usr/X11R6/bin

One possible solution would be to name dll's like this:

libfoo.1.1.cygwin.dll and play tricks in the implib.

>2) should new libraries version their dll's when API/ABI changes?
>
>--Chuck

Yes, please, the versioning of cygwin-contributed dll's should go with
the versioning of the original code that was used for porting.

Normally this would mean that a dll must exist thay has versioning
equivalent to the soname that was set in the corresponding
unix.library. With one exeption: Libraries should never be build with
full mayor.minor.patch version number because links do not work under
native win98/95 (crap)-OS. The maximum dll-name should include
mayor.minor as a version number.

Example:

Package foo has version 1.1.2 and builds a unix-so with soname 1.1
libfoo.1.1.dll is the correctly named dll
libfoo.dll.a is the imp-lib with references to libfoo.1.1.dll burned
in

libfoo.1.1.2.dll is an ivalid dll-name (because it uses
mayor.minor.patch versioning)

Michael Ring

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com