Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3E53075D.7010609@ece.gatech.edu> Date: Tue, 18 Feb 2003 23:26:05 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: [avail for test] libtool-devel-20030216-1 References: <20030219023640 DOT GE26147 AT redhat DOT com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >>However, it could easily be standard. I know, but we've been thru this before. This is just as big a PITA as -mno-cygwin. (OTOH, it's a PITA for *you*, but causes *me* no pain...Hmmm, I like it. ) > I could include a >>i686-pc-mingw32-gcc >>and a i686-pc-mingw-ld in the gcc distribution. And, I could also alias >>all of the i686-pc-cygwin-* tools to i686-pc-mingw32-*. That >>would provide >>the equivalent of a cross compilation environment for cygwin. Yes, if the "-mingw-" versions automagically "add" -mno-cygwin before handing off to the real cygwin tools. (I assume you're talking about wrappers, not full-out binaries...although, a "real" i686-pc-mingw32-gcc (and -ld, -g++, etc) would be nice, since the platform defaults are different. In the medium term, I expect that --pseudo-relocs will be the default for ld/cygwin, but Danny [rightly] doesn't want to do that for ld/mingw.) >> >>Then you just have to say >> >>configure --host=i686-pc-mingw32 --target=i686-pc-mingw32 >>--build=i686-pc-cygwin >> >>and you bypass the arbitrary distinction of having a whole build system, >>based on cygwin which exists just so that uname returns 'mingw', >>or whatever. >> >>(Yes, I know that MSYS does other things, too, but this does get rid of >>the requirement of using MSYS just to make it easy to use >>autoconf/libtool) I like it. It makes things easier for those of use who live in cygwin most of the time, but occasionally want to build native stuff. There will still be a reason for MSYS, tho: for people who don't want unixoid tools, but simply want a free(BEERspeech) monolithic windows compiler suite. Download, unpack, go. Anyway, with the pseudo-cross environment you still have to worry about accidentally linking in cygwin's libraries (like -lz, -lpng, etc) -- I think. I haven't looked closely at the current state of the art in cygwin's compiler realm... And where do you put your (personal) mingw libs? /usr/lib/mingw and /usr/local/lib/mingw ? That gets messy, fast (I've been working with Irix lately; geez -- one machine, supports three simultaneous ABIs. Share the same includes and executables, but "Old 32bit ABI" libraries go in /usr/lib, "New 32bit ABI" go in /usr/lib32, and "64bit ABI" go in /usr/lib64. And make sure to -rpath everything, so you get the right ABI for any system-level dependencies. Blech. We do NOT want to go down that road. Userland libs/includes/etc for mingw-on-cygwin should be keep OUT of the main /usr/ heirarchy, with the obvious exceptions of the current contents of /usr/lib/w32api and /usr/lib/mingw) sometimes, it's just cleaner to have a whole 'nother tree like /opt/mingw...(or heck, /mingw -- then we'd *really* look like MSYS, and we could simply unpack mingw packages for our use) this would be simply a convention, unenforced by gcc or binutils, similar to the one we use for X stuff: "hey developers, when compiling in "mingw" mode for the cygwin environment, make sure to use --prefix=/mingw or --prefix=/mingw/local along with your --host= --build= --target= magic, if you want your stuff to play nicely with everyone else's") On the other hand, *I* don't want to be expected to provide -mingw-on-cygwin versions of my libraries (although for the ones used by setup: libz and libbz2, I could be persuaded -- since that would allow Robert to remove YARC* of libz from CVS). And cgf stated long ago that he wouldn't allow a whole bunch of mingw packages on the standard cygwin mirror system. (Which doesn't preclude someone ELSE from setting up a *separate* system and telling folks to "point setup at...") *YARC: yet another redundant copy > I use a slightly different technique > > I maintain a separate /$MINGW development tree within my $CYGWIN tree > and make sure that $MINGW/bin comes before /bin in $PATH then > ./configure --prefix=$MINGW --host=mingw > seems to work fine from a bash shell this is what I did -- but it sure took a lot of disk space. I like the idea of sharing /usr/include/w32api, /usr/lib/w32api, etc. --Chuck -- 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/