Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com From: Chris Faylor Date: Wed, 5 Apr 2000 10:59:12 -0400 To: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: mingw using wrong errno definition Message-ID: <20000405105912.B1264@cygnus.com> Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com Mail-Followup-To: cgf AT cygnus DOT com, cygwin-developers AT sourceware DOT cygnus DOT com References: <20000405071501 DOT 75956 DOT qmail AT hotmail DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <20000405071501.75956.qmail@hotmail.com>; from parkerrd@hotmail.com on Wed, Apr 05, 2000 at 12:15:00AM -0700 On Wed, Apr 05, 2000 at 12:15:00AM -0700, Ron Parker wrote: >In an attempt to build the cinstall source without using MSVC, I have >made the following minor changes to my local copy of the winsup source >from CVS. One corrects an obvious typo and the other was so I could >configure and build everything in one pass from the main directory >including the cinstall code. > >Index: winsup/configure.in >=================================================================== >RCS file: /cvs/src/src/winsup/configure.in,v >retrieving revision 1.1.1.1 >diff -r1.1.1.1 configure.in >60c60 >< SUBDIRS="cygwin w32api mingw utils doc" >--- >>SUBDIRS="cygwin w32api mingw utils doc cinstall" Looks good. Go ahead and check this in. >Index: winsup/cinstall/Makefile.in >=================================================================== >RCS file: /cvs/src/src/winsup/cinstall/Makefile.in,v >retrieving revision 1.2 >diff -r1.2 Makefile.in >102c102 >< zlib/zlibcygw.a: zlib/Makefile >--- >>zlib/libzcygw.a: zlib/Makefile I don't get this one. My version of Makefile.in doesn't have a blank line before the "zlib" here. I've changed this to $(ZLIB) anyway since that is more consistent. >`/home/rdparker/cygwin/obj/i686-pc-cygwin/winsup/cinstall/zlib' >gcc -o setup.exe error.o memory.o setup.o strarry.o cinstall.o -g -O2 >-mno-cygwin zlib/libzcygw.a -lole32 -lwininet -lnetapi32 -ladvapi32 >-luuid >zlib/libzcygw.a(gzio.o): In function `gz_open': >/home/rdparker/cygwin/obj/i686-pc-cygwin/winsup/cinstall/zlib/../../../../../src/winsup/cinstall/zlib/gzio.c:155: >undefined reference to `__errno' >zlib/libzcygw.a(gzio.o): In function `get_byte': >/home/rdparker/cygwin/obj/i686-pc-cygwin/winsup/cinstall/zlib/../../../../../src/winsup/cinstall/zlib/gzio.c:241: >undefined reference to `__errno' >zlib/libzcygw.a(gzio.o): In function `destroy': >/home/rdparker/cygwin/obj/i686-pc-cygwin/winsup/cinstall/zlib/../../../../../src/winsup/cinstall/zlib/gzio.c:338: >undefined reference to `__errno' >zlib/libzcygw.a(gzio.o): In function `gzread': >/home/rdparker/cygwin/obj/i686-pc-cygwin/winsup/cinstall/zlib/../../../../../src/winsup/cinstall/zlib/gzio.c:399: >undefined reference to `__errno' >zlib/libzcygw.a(gzio.o): In function `gzerror': >/home/rdparker/cygwin/obj/i686-pc-cygwin/winsup/cinstall/zlib/../../../../../src/winsup/cinstall/zlib/gzio.c:865: >undefined reference to `__errno' >collect2: ld returned 1 exit status >gcc: file path prefix >`/home/rdparker/cygwin/obj/i686-pc-cygwin/winsup/mingw/' never used >make: *** [setup.exe] Error 1 > >It appears that despite the "-mno-cygwin >-I../../../../src/winsup/mingw/include" switches to gcc, it is still >picking up the standard cygwin definition of errno. I am too tired to >have a quick solution to this and I am not sure I would know the right >one if I were completely awake. Thought I might luck out and fine an >answer in my mailbox in the morning. :^) I saw this at one point when I was building cinstall. I thought it came from running make in the zlib directory rather than letting it be handled by the cinstall Makefile. I didn't get around to changing the zlib Makefile to correctly set all of the includes so I used the tried-and-true devo technique of relying on the fact that it was being run from a higher-level directory. Can you try doing a "make clean all" in the cinstall directory and see if that "fixes" things? cgf