This is the mail archive of the
mailing list for the Cygwin project.
RE: Conflict CYGWIN-autoconf(2.13)
- To: 'Erik Hensema' <erik dot hensema at group2000 dot nl>, cygwin at sourceware dot cygnus dot com
- Subject: RE: Conflict CYGWIN-autoconf(2.13)
- From: Heribert Dahms <heribert_dahms at icon-gmbh dot de>
- Date: Fri, 29 Oct 1999 23:55:24 +0200
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 (email@example.com)
> -----Original Message-----
> From: Erik Hensema [SMTP:firstname.lastname@example.org]
> Sent: Friday, October 29, 1999 12:03
> To: email@example.com
> Subject: RE: Conflict CYGWIN-autoconf(2.13)
> > -----Original Message-----
> > From: Kai Henningsen [mailto:firstname.lastname@example.org]
> > 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
> While this is true, it also breaks Cygwin ;-) Report this as a bug to
> autoconf people. The variable should be renamed to something else, let
> think..... hmmmm.... CYGWIN_DLL?
> Want to unsubscribe from this list?
> Send a message to email@example.com
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org