[avail for test] libtool-devel-20030216-1

[Charles Wilson]

>>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. <g> )

> 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(<big>BEER</big><small>speech</small>) 
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/