Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <17B78BDF120BD411B70100500422FC6309E2E3@IIS000>
From: Bernard Dautrevaux <Dautrevaux AT microprocess DOT com>
To: "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Subject: RE: CYGWIN1.DLL
Date: Wed, 18 Jul 2001 16:10:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> Sent: Wednesday, July 18, 2001 7:02 AM
> To: cygwin AT cygwin DOT com
> Subject: Re: CYGWIN1.DLL
> 
> 
> On Wed, Jul 18, 2001 at 08:41:26AM +0400, Andrej Borsenkow wrote:
> >yOn Tue, 17 Jul 2001, Christopher Faylor wrote:
> >
> >> On Tue, Jul 17, 2001 at 10:09:49AM -0700, Eric M. Monsler wrote:
> >> >But, I did want to point out that there are good reasons 
> for desiring a
> >> >statically linked executable that are not in violation of 
> the cygwin
> >> >license.
> >>
> >> I don't think I've seen a good reason for this in this thread.
> >>
> >> The fact that you could have two disparate versions of the 
> cygwin DLL
> >> on your system is not, in any way, an argument for a 
> statically linked
> >> cygwin.  Conflicts between two versions of cygwin have nothing to
> >> do with the DLLness of Cygwin.
> >>
> >
> >Actually, it is very good argument *against* static linking. 
> In this case
> >nothing can help if you have two different programs linked with two
> >different versions. Somebody will have to rebuild every 
> single program
> >with new version of Cygwin as soon it is released ... nightmare.
> 
> Right!  Good point.
> 
> >Probably, intelligent setup that checks for existence of cygwin dll
> >and download/update it only if needed makes more sense.
> 
> Actually the current version of setup.exe has some 
> preliminary code for
> doing just this.
> 

The problem with relying on setup to fix that (e.g. suppressing any already
present cygwin1.dll on the system when installing cygwin) is only part of
the problem.

If I install a cygwin1.dll with my program, where should I install it?
obviously in some directory that is in the *standard* path for windows
programs, so probably in \WINNT\system32 (as /cygwin/bin is usually NOT in
the path for standard windows program).

So if I install my program AFTER cygwin, I got two cygwin1.dll and if I
install cygwin after my program I got only one, but my program probably no
longer run...

I think that's part of the dreadfull DLL-HELL syndrom :-)

Part of the problem will be avoided if setup installed cygwin1.dll in
/WINNT/system32, but this had probably been over-discussed already :-)

The only satisfying solution I've found personally is delivering a reduced
(ought to be minimal but is not) cygwin install with my program (on the same
CDROM).

HTH

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux AT microprocess DOT com
		b DOT dautrevaux AT usa DOT net
-------------------------------------------- 

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