Mail Archives: cygwin/1999/10/29/18:02:22
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 AT icon-gmbh DOT de)
> -----Original Message-----
> From: Erik Hensema [SMTP:erik DOT hensema AT group2000 DOT nl]
> Sent: Friday, October 29, 1999 12:03
> To: cygwin AT sourceware DOT cygnus DOT com
> Subject: RE: Conflict CYGWIN-autoconf(2.13)
>
> > -----Original Message-----
> > From: Kai Henningsen [mailto:kai AT cats DOT 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 AT sourceware DOT cygnus DOT com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -