Conflict CYGWIN-autoconf(2.13)

Heribert Dahms heribert_dahms@icon-gmbh.de
Sun Oct 31 19:54:00 GMT 1999


Hi Kai,

how exactly does it break Cygwin?
If autoconf is run from within Cygwin's bash, cygwin.dll is already
loaded and CYGWIN is IIRC honored only at initial startup.
The you say autoconf sets CYGWIN in either case, so the
previous value doesn't matter for the to-be-configured stuff, and
the new value does not influence the already loaded cygwin.dll.

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Erik Hensema [SMTP:erik.hensema@group2000.nl]
> Sent:	Friday, October 29, 1999 12:03
> To:	cygwin@sourceware.cygnus.com
> Subject:	RE: Conflict CYGWIN-autoconf(2.13)
> 
> > -----Original Message-----
> > From: Kai Henningsen [ mailto:kai@cats.ms ]
> >
> > Just seen in the autoconf 2.13 documentation:
> > 
> > 
> >  - Macro: AC_CYGWIN
> >      Checks for the Cygwin environment.  If present, sets shell 
> > variable
> >      `CYGWIN' to `yes'.  If not present, sets `CYGWIN' to the empty
> >      string.
> > 
> > 
> > This obviously conflicts with using CYGWIN to control cygwin1.dll 
> > options.
> 
> I guess the autoconf people included this to make autoconf Cygwin
> aware.
> While this is true, it also breaks Cygwin ;-) Report this as a bug to
> the
> autoconf people. The variable should be renamed to something else, let
> me
> think..... hmmmm.... CYGWIN_DLL?
> 
> > 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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



More information about the Cygwin mailing list