This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: mismatched dll

> OK. I understand the concept of having each application share a single
> .dll, this is to save space. Unix does this with shared objects. 
> However, here's what I don't understand. Please explain to me why 
> my thinking is fault. A program called p_v1 depends on v1.dll.
> Another program called p_v2 depends on v2.dll. For every p_v1 or 
> p_v2 you start, only a single version of the associated dll is opened.

The difference is not the .dll itself, but the shared memory region
that cygwin uses.  Every process linked against cygwin1.dll
opens a shared memory region, known by a fixed name/location, so
that information can be passed between cygwin processes
via this shared memory area.  And there are enough POSIX
semantics that require sharing info between cygwin processes
that it is QUITE difficult to try opening different shared
memory regions when different .dlls are used.

> The reason this design is nice is because you can have multiple versions
> of the .dll installed, and they will be shared between executables
> nicely.

Yes, we know.  For example, /bin/cygreadline[4-6].dll all nicely
coexist, so that your application can choose which API level
of readline you want to use (4.x, 5.0 with 32-bit offset, or 5.x
with 64-bit offset).

> By moving the cygwin1.dll in the executable directory, things begin to
> work. However, I don't understand how it's assumed that the new
> cygwin1.dll acts the same as the one the executable was linked against.
> See what I mean?

There's a difference here.  Cygwin does not maintain binary
compatibility of its use of its shared memory region between
versions.  But it DOES maintain binary compatibility of the API
it exposes.  Cygwin releases try very hard to guarantee that
something compiled against an older cygwin1.dll will continue
to run when a newer cygwin1.dll is put in its place.  The
underlying details may change (such as the shared memory
region), but the API continues to work.  And that is exactly
what shared libraries were invented for.

> Another reason I'm asking is, I was trying to think of how I could
> package CGDB for people.

By far the easiest is to tell them to download cygwin themselves,
then you don't have to worry about it.  But yes, this is not
very user-friendly.  So you will have to come up with some
scheme where if cygwin is already on the machine, you make
sure it is new enough for your needs, and if it is not present,
you make sure the user is informed that you are installing a
cygwin1.dll and that if they ever want more cygwin features
they should replace/delete the one you installed.  Otherwise,
you risk becoming the dreaded

Oh, and remember that cygwin1.dll is GPLd, so if you distribute
the dll yourself, you must also distribute the source code for
the version you are shipping, as well as make sure your
own project is open source per the cygwin license.

Eric Blake

Unsubscribe info:
Problem reports:

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