Peter Rosin wrote: > First off, your patch works like a charm on MSYS/MSVC, and I generally > like it. > > But a couple of questions are open, when did native MinGW "ar" enter the > picture when $build = cygwin and why is there a problem with leakage > of paths from the "other" environment? I thought the tools when $build > is Cygwin are ordinary cross tools (albeit with a strange name so far)?
I was deliberately testing the case where you use the MinGW native toolchain from the cygwin environment. I had the impression that was pretty common, because MSYS is, well, limited. Old. Slow to be updated. Based off an ancient fork of cygwin. Not many ported utilities. Heck, I'm not even sure it works on Vista with UAC (maybe it does). So, I figured a lot of folks probably try to drive the "official" MinGW gcc using the cygwin bash/tools rather than the MSYS bash/tools. But maybe they all lie, like Danny does below... [NB: see thread "RFD: cygwin + *native* MinGW compiler" http://cygwin.com/ml/cygwin/2009-01/msg00808.html ] In fact, Danny Smith [*] stated: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01162.html [I use most often...] -build=i686-pc-mingw32 --host=i686-pc-mingw32 --target=i686-pc-mingw32 [with] cygwin bash and tools [*] ex-MinGW maintainer /of/ gcc, now currently one of the gcc maintainers /for/ MinGW. (Trust me, the two roles sound similar but are quite different in practice.) Point is, I don't want to break Danny's use case! Now, Danny's actually lying to configure, when he claims that $build == mingw32, when it is actually cygwin. And, without any other considerations, his use case may break my patch (or vice versa). You'd end up calling func_msys_to_mingw, which relies on the msys "magic" path conversion logic: ( cmd //c echo "$1" ) MSYS (but not cygwin) notices that cmd is a native win32 program, and that there is a path-like argument "$1". MSYS (but not cygwin) will then automatically convert $1 to DOS format, before spawning the cmd process -- which echos the converted path to stdout, where we can grab it. MSYS (but not cygwin) also turns '//c' into '/c' (the extra slash means "don't use the MSYS mount table to convert this "path") -- this is how you pass win32-style switches to native programs. IIRC, there's some complicated logic to determine whether a given argument that begins with two slashes is a "switch" like /EHsc or a unix-format SMB path like //server/share/path/to/file. On cygwin, //c stays //c, and "$1" stays in unix format, and 'cmd' gets very confused by the '//c' non-"switch". Bang, you're dead (well, libtool prints a warning and uses the unix-format path, so...you're a zombie, and you'll die later). Maybe if $to_host_path_cmd and $to_host_pathlist_cmd were cached variables, then folks who (a) know what they are doing, and (b) want to lie, can do cygwin$ export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert cygwin$ export lt_cv_to_host_pathlist_cmd=func_cygwin_to_mingw_pathlist_convert cygwin$ path/to/configure \ --build=i686-pc-mingw32 \ --host=i686-pc-mingw32 \ --target=i686-pc-mingw32 ??? ========= Now, you're certainly right in one respect: if we can assume that --build=cygwin --host=mingw means "my compiler is a generic cygwin-hosted mingw cross compiler" and NOT "I'm using the native mingw compiler from a weird (cygwin) environment" -- then things are a lot easier. Heck, that probably works already. And I'd test it...if I had an accessible cross compiler of that sort... But at present, the cygwin distro does not supply such a beast. It will, very soon: once the official cygwin gcc-4.[34] packages are rolled out, they will no longer support -mno-cygwin, so we'll be obliged to provide a true cygwin-host mingw-target cross compiler just to self-host and build some of our own tools, like setup.exe. But...I'm a little confused -- to verify: A "normal" cross compiler would itself have been configured as "--build=cygwin --host=cygwin --target=mingw" (and if gcc used a libtool with my patch, it'd hit func_noop_path_convert because $build==$host, which is what we want and expect). Then, if I wanted to USE that cross-compiler to build pkg X, I'd configure pkg X as "--build=cygwin --host=mingw", so if pkg X used libtool we'd hit func_cygwin_to_mingw_path_convert etc (which again, is what we want and expect). Right? Good... > However, all that aside, is func_noop_path_convert a good idea? > Wouldn't it be better to just leave to_host_path_cmd empty in that > case and test for that in func_to_host_path? Or is an unconditional > eval as cheap as an if test -n "$foo", in the common case when the > eval isn't needed? > > func_to_host_path () > { > if test -n "$to_host_path_cmd"; then > eval '$to_host_path_cmd "$1"' > else > func_to_host_path_result=$1 > fi > } I'm not sure. I was going for clarity of code, and figured we could determine if any speedups were needed or possible later. To me, it's much clearer if a $cmd variable is assigned to a func_noop() target, as opposed to leaving the $cmd variable empty and requiring the reader to either assume or track down proof that $cmd="" implies a "no-op": func_to_host_path_result=$1. Now, this is just a wild guess, but I would think that there isn't much difference in speed between the my original code and the suggested code above, given that (a) everything's a builtin, and (b) there are no subshells for the func_noop_ case. > Anyway, I have rewritten [1] to hook into the new refactored functions > in your patch via a func_to_tool_path function, controlled with a > to_tool_path_cmd variable. I'll hold that patch until the dust settles, > there are too many pending patches and my git "tree" looks a bit like > a maze... Cool. I appreciate you working with me on this. -- Chuck
