This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]