This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030216-1
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/