On 1/7/2011 3:02 AM, Peter Rosin wrote: > Den 2011-01-06 21:29 skrev Ralf Wildenhues: >> * Peter Rosin wrote on Tue, Jan 04, 2011 at 05:44:58PM CET: >>> Before I tie up the lose ends with this patch, I wonder if Ralf (or someone >>> else) could tell me if I should also fix the other assignments of >>> old_archive_cmds -- such as in the below snippet -- or is that completely >>> irrelevant? >> >> I wouldn't change them without being sure that the changes are >> necessary. > > Well, they are necessary, but in cases which are, errhm, convoluted... > > Such as: win32-hosted cross-tools (I mean native win32 here, not > dependent on Cygwin or MSYS) for targeting irix (or whatever) and > running them from Cygwin (or Wine) instead of MSYS. > > I think I'll skip the extra changes, as someone doing the above needs > a clue-bat anyway.
Err...that's not really uncommon. Take the following fer-instance: 1) You use a "vendor-provided" gcc for your fav embedded target 1a) naturally, it's a MinGW->$foo cross compiler 2) But, you like to work from a cygwin shell because it doesn't suck as bad as dosbox, and provides tools that MSYS does not. Now, MOST of the time, if you're using a vendor-provided compiler, you're also going to use the vendor-provided IDE, so...the fact that you like to "play" in the cygwin shell doesn't matter; the IDE doesn't use "your" shell anyway. But...if you step outside of the IDE...say, you just want to use the normal configure/make process with --host=$foo CC="/path/to/vendor/bin/gcc", since you don't really want to set up an IDE project for $third-party-package-with-perfectly-good-autoconfigury, do you really need a cluebat? "Don't do that, download and install the (limited in functionality compared to cygwin) MSYS environment, even though you are not using "real" MinGW gcc, but a vendor toolchain?" Or...a few more, already identified and well-understood changes in libtool? -- Chuck
