Peter Rosin wrote: > Den 2009-02-24 04:04 skrev Charles Wilson: >> 01-fix-dlpreopen-with-disable-static.patch >> 02-refactor-cwrapper-cross-compile-and-add-cygwin.patch >> 03-document-and-test-cwrapper-macro.patch >> 04-pr-dumpbin-link-support.patch >> 05-pr-lib-prefix-for-archive-name-ltdl.patch >> 06-pr-preload-heed-libname_spec.patch >> 07-pr-add-func_to_tool_path.patch >> 08-pr-use-LT_AR-internally-and-convert-filenames-to-host-format.patch >> 09-pr-allow-ms-lib-archiver.patch > You did notice that [3] "use-LT_AR..." depends on [1] "allow-ms-lib...", so > why did you not cherry-pick them (or whatever you did) in that order?
Because I'm not a git whiz. I didn't cherry pick them, and when I attempted to create a topic branch to merge all these changes, I seriously hosed it, and got a ton of changes I didn't want. So, I explicitly (and manually) created patches from the commits I wanted: git diff <rev1>..<rev2> And then manually merged them into a new topic branch. Then committing them to that branch. So, the only way I "noticed" that 08-pr-use-LT_AR needed 09-pr-allow-ms, was after I had manually merged 08-, my branch was broken. I figured out why, found the appropriate patch (e.g. single commit) that fixed the issue, and manually applied that patch to my topic branch. I guess I could've THEN done a rebase -i, and reordered the commits. But I didn't. > You > have also included some bits of [2] "libtool-ar" in your "use-LT_AR..." > commit, but not all of it, which seems like a mistake since [3] depends > on [2] as well. As is, I don't expect "use-LT_AR..." to work as I > intended... I was afraid of that. I *thought* -- but was wrong -- that ALL of the pr-ms patches were independent and consisted of a single commit on their individual topic branch, so that I could just pick the ones I thought (a) wouldn't break cygwin/mingw native, (b) were relatively easy to (manually) merge, and (c) had significant interaction with my re-re-re-re-re-revised pending patches, such that they *needed* to be harmonized. Under those assumptions, then picking 5 (or 6, as it turned out) of your patches and doing a little janitor/harmonization work on them would (a) help you, (b) not break anything, and (c) incrementally add some functionality -- even if untested in my build. And then I discovered that the patches were not so independent, after all (08- vs. 09-). But, I'd come far enough -- and cygwin passed all of ITS regressions after a solid WEEK [*] of testing -- that I didn't want to revert them and release cygwin with only my three patches, nor did I want to let my janitor/harmonization efforts disappear into the aether. So, I went with what I had (even it it added only partial, and maybe -- as you point out -- /broken/ -- new functionality; since the cygwin build doesn't USE that new functionality, it didn't matter. [*] Not libtool's fault, this time. I got hit by the dreaded "perl fork failure: can't remap DLL in child to same address as in parent" problem. Ugh. See http://cygwin.com/ml/cygwin/2009-02/msg00488.html. > Your resulting code is e.g. in some cases setting LT_AR to: > LT_AR='$(SHELL) $(top_builddir)/libtool --quiet --mode=ar' > but your libtool script does not support --mode=ar Yep. The patches/commits weren't quite as independent as I thought, and some that I pseudo-cherry-picked depended on others that I didn't. > However, I'm not sure it is a wise thing to feed --mode=ar to the > wilderness > without an "ok" on the interface from at least one libtool maintainer? Meh. Cygwin doesn't use it, and it's broken so nobody will actually be ABLE to use it, so I might get some complaints on the cygwin list. But I doubt any of those complaints will show up on this list; and if they do, just blame me for pushing untested patches into the wild and tell the OP to check the real pr-msvc branch if they're really interested. > Note that I made a mistake when I commited [2]. It was never intended to > go into the pr-msvc-support branch without the above "ok" [4]. Oh. Didn't realize that. > And the 07- patch seems to break ordinary crosses. Well now, that /would/ be bad. > My version assumed that > the toolchain is an ordinary cross toolchain which understands $build > paths, > except in cases where it knows it doesn't (i.e. $host=mingw, $build=mingw). > Your version assumes that the toolchain is not ordinary, but instead one > that understands $host paths (at least when $host is mingw or cygwin). That wasn't my intent. I was attempting to add the caching behavior (which, because of autoconf limitations, requires a whole separate case...esac tree from the to_host_path_cmd tree: you can't cache two different variables at once). But I hoped that, while using the different m4 code structure, the behavior stayed the same as yours. However, because I didn't pseudo-cherry-pick the patch which actually USES the new func_to_tool_path function...I didn't actually *break* anything in my build. But I can see that if you accepted my 07- patch, it would break your pre-existing USES of func_to_tool_path. However, the "fix" to my 07- patch is just a couple of one-liners, right? > That > seems dead wrong to me, please explain those changes. I can understand it > for the $build=cygwin, $host=mingw case since there is not yet an ordinary > Cygwin cross toolchain package provided, but I don't agree with it. I agree with you. Even in the cygwin->mingw case, it SHOULD still think that the compiler is an ordinary cross-compiler. Users of www.mingw.org-gcc within cygwin $build (but NOT existing cygwin-gcc -mno-cygwin) should use the caching facility to override: $ export lt_cv_to_tool_path_cmd=func_cygwin_to_mingw_path_convert $ ../src/configure --build=cygwin --host=mingw ... > But > with $build=[unix] it is almost certain that the toolchain is an ordinary > cross toolchain and not some hybrid lying bastard, and in those cases you > need: > lt_cv_to_tool_path_cmd=func_noop_path_convert Yep. You're right. > If you are trying to run some win32-native toolchain in Wine, that's the > strange case where you need to override lt_cv_to_tool_path_cmd. Such an > override should IMHO not be needed when you use an ordinary mingw cross > toolchain. Agree. Again, these fixes are all just a few one-liner mods to 07-, in the new cachified m4 code structure. > But do note that I gathered this from the tar.bz2 archive you sent > here, and I have not checked what is actually in the cygwin release. That IS the cygwin release (with one cosmetic change. The cygwin package has the incorrect name for the 09- patch. I forgot to use the -pr- prefix). From the cygwin-specific README: * This version marks the beginning of cygwin-1.7 specific ports. Releases 2.2.7X-2 thru 2.2.7X-9 are reserved for cygwin-1.5. * Use stock cygport 0.9.4 * Import several fixes waiting upstream: - allow -dlpreopen with -disable-shared - enable cwrapper execution in unix-to-cygwin cross environment, assuming $build is x86, wine installed, and binfmt kernel extension in use. - additional cwrapper documentation - Some other patches from the msvc branch (not strictly necessary for cygwin). This is not a complete set of the changes from the pr-msvc branch, but only a few. * Passes all regression tests. * Original tarball taken 2009-02-16 21:59:34 +0100 from git revision 9e9ba5e0e2c0b3f33ee44081c5bc3f0b8991aebd So, I did a git checkout at 939ba5e0, and then used the cygport build machinery (it's kinda like gentoo emerge) to apply 01, 02, 03, ... 09, bootstrap, configure, and compile. -- Chuck