Re: error trying to compile anything

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Okay people:

0) "short filenames" is NOT the reason for "cygwin1.dll".  It is called 
that because it is the 1st stable backward compatible DLL.  Everything 
compiled against any version of cygwin1.dll in the past will work with 
any newer version without relinking (but not vice versa).  For instance:
   a)  build foo.exe while cygwin1.dll(1.3.1) is on your system
       foo.exe will work with cygwin1.dll(1.3.2, 1.3.3, 1.3.4, 1.4.0,
       etc) WITHOUT recompiling.

   b) However, if you build foo.exe while cygwin1.dll(1.3.1) is on
      your system, you should NOT expect that it will work if you
      revert your cygwin1.dll to an EARLIER version, such as
      1.3.0, 1.1.8, etc.

When a) is no longer true, then we will bump the DLL name to "cygwin2.dll".

1) cygwin supports symlinks -- but microsoft does not.  And it is the 
Microsoft Windows Runtime Loader that must search out and load the DLLs 
into memory.  Therefore, you cannot have "cygwin-1.1.3.dll -> 
cygwin-1.1.6.dll" and expect programs that want cygwin-1.1.3.dll to 
work.  Therefore you must have actual copies of every cygwin-x.y.z dll 
on your system that is needed by some executable.  Symlinks not allowed.

2) If you have multiple cygwin dlls on a system, then they must all use 
different named shared memory areas (otherwise bad things will happen). 
  This means that foo.exe (depends on cygwin-1.1.3.dll) and bar.exe 
(depends on cygwin-1.1.4.dll) can't communicate very well.

3) With strongly versioned DLLs, you can't fix bugs.  If 
cygwin-1.1.4.dll has a bug, then everything compiled against it will 
have that bug.  When cygwin-1.1.5.dll comes out, you'll have to 
recompile all of those applications to take advantage of the bug fix. 
Unix gets around this by having a MAJOR_VERSION (libfoo.so.X) and all 
the strongly versioned development links are just pointers to that 
(libfoo.so.X.Y.Z -> libfoo.so.X).  On windows, we can't really do that 
(see point #1 above).  So, you might as well be linking everything 
statically -- because you lose the ability to slipstream bugfixes.

See the "DLL naming" thread in the cygwin-apps mailing list archive from 
1.5years ago for more information.

Reini, you don't know as much about "real" versioning as you think. 
Check the libtool mailing list and documentation for info on version 
strings, (c - a) numbering, and backward compatibility.

--Chuck


Reini Urban wrote:

> Reini:
> 
>>>what about "real" versioning of the cygwin.dll finally?
>>>perl did the half-baked thing (perl56.dll), though I heavily voted for
>>>the real thing that times.
>>>cygwin also (cygwin1.dll). why not cygwin-$(version).dll => cygwin-1.1.6.dll
>>>
>>>this is not FAT16 anymore. we have w95/98/ME and NT systems only.
>>>all support long filenames.
>>>duplicate dll's will be gone. microsoft dll hell will be past tense.
>>>
>  
> "Larry Hall (RFK Partners, Inc)" schrieb:
> 
>>The issue is not as simple as just DLL names.  Of course, if you want
>>to show us all your dandy solution, provide a patch and it will be
>>thoughtfully reviewed.
>>
> 
> is this list about politics (software design) or patches (software
> implementation) only?
> 
> of course dll names are just part of the game. but an important one, 
> which bit microsoft heavily AFAIK. 
> cygwin does support softlinks, so we should use them.
> the implementation is trivial, but there should be consense.
> 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/