Re: FYI: latest official cygwin libtool
Den 2009-02-26 05:39 skrev Charles Wilson: Peter Rosin wrote: *snip* 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. You seem to think that the libtool you release in cygwin is limited to cygwin users. That is not the case. When some upstream package maintainer actually uses cygwin for development (I do), libtoolizes his/her package with your patches (I don't, but that's only because I happen to know there's a difference), releases a tarball, then every end-user of that package gets your patches. I think you have to consider that... 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. Hmmm, I now realize that I was confusing your patch with my unpublished rework of the patch that you found in the preview git tree. My reworked patch looks like this (I.e. it's no longer intertwined with the to_host check): +AC_MSG_CHECKING([how to convert $build paths to toolchain format]) +AC_CACHE_VAL(lt_cv_to_tool_path_cmd, +[#assume ordinary cross tools, or native build. +lt_to_tool_path_cmd=func_noop_path_convert +case $host in + *mingw* ) +case $build in + *mingw* ) # actually msys +lt_cv_to_tool_path_cmd=func_msys_to_mingw_path_convert +;; +esac +;; +esac +]) +to_tool_path_cmd=$lt_cv_to_tool_path_cmd +AC_MSG_RESULT([$lt_cv_to_tool_path_cmd]) +_LT_DECL([to_tool_path_cmd], [lt_cv_to_tool_path_cmd], + [0], [convert $build paths to toolchain format])dnl +AC_SUBST([to_tool_path_cmd])dnl This mistake of mine made it hard for me to understand why you had fleshed that out with all the other cases from the to_host case-tree. But of course you hadn't fleshed out anything, you wrote the cache check independently, and it looked so similar to my version (we both copied your to_host code) that I was confused. 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. Right, now I see. You have not included enough to make it matter. Sorry for the panic attack... 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? See above :-) *snip* The patches in pr-msvc-support and in my preview git tree are not independent, even when they touch the same area, for this reason: The patches *in* pr-msvc-support have been approved by some libtool maintainer (read: Ralf) (not counting the 4 patches that I pushed by mistake). Then there are patches waiting for review to get into the branch (or master), and lastly there are patches that depends on external patches not yet fully reviewed. So, three classes: a) in the branch (except 4 patches belonging in b) b) waiting for review c) depending on externals In the case of the AR patches there is, as you've discovered, patches in all of a, b and c. Also, when something has gone into the branch, I'm hesitant to change it. I feel that it is much better to just add patches on top in order to preserve history. This makes it harder to cherry-pick, of course. The complexities and the length of my patch queue is not all my fault. Believe me, noone would be happier than me if it wasn't such a mess. Cheers, Peter
Re: FYI: latest official cygwin libtool
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
FYI: latest official cygwin libtool
I've updated cygwin's libtool packages, using git master at 2009-02-16 21:59:34 +0100 from git revision 9e9ba5e0e2c0b3f33ee44081c5bc3f0b8991aebd (Do not pass $INSTALL via TESTS_ENVIRONMENT.), plus a sequence of patches. I'm posting these mostly for Peter's benefit, as I included some (but not all) of his pr-msvc patches -- but had to revise some of them (esp. add-func_to_tool_path) a bit. Peter, you might want to look at 07-pr-add-func_to_tool_path.patch and 08-pr-use-LT_AR-... Also, I found that 08-pr doesn't work standalone; it requires 09-pr-allow-ms-lib-archiver.patch or you get build errors. 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 Note that 01-, 02-, and 03- have already appeared on this list in the exact form included. The 0x-pr patches...probably not so much, because of ripple effects from the first three, but I'll leave that to Peter to sort out. g. While my build was cygwin native (that is, I didn't exercise much of the pr-msvc code), it passed all regressions on both cygwin-1.5 and cygwin-1.7 -- so the pr-patches do no harm. I'm going to ask (on the cygwin list) for some test reports by folks who routinely use unix-cygwin cross environments, so maybe we'll get a little in the wild feedback about 02-refactor-cwrapper-cross-compile-and-add-cygwin.patch. -- Chuck 2008-08-02 Peter Rosin ... Allow Microsoft lib to be used as the archiver. * libltdl/m4/libtool.m4: Add $AR_SEP between $AR_FLAGS and the archive file name in all $AR commands. (_LT_CMD_OLD_ARCHIVE): Use _LT_PROG_AR to find archiver, not AC_CHECK_TOOL. * libltdl/config/ltmain.m4sh (func_extract_an_archive): Add support for archivers that only supports extracting one member at a time and otherwise adjust to the above libtool.m4 changes. Also, add $AR_SEP to the $AR invocations. * Makefile.am: Pass AR, AR_FLAGS and AR_SEP through to the testsuite. * tests/archive-in-archive.at: Extract archive name from the .la file instead of hardcoding the name, and allow different archivers. 2009-01-26 Peter Rosin ... Use LT_AR internally and convert archive file to host format * libltdl/m4/libtool.m4 (_LT_PROG_AR): Export LT_AR and LT_ARFLAGS to the libtool script. (_LT_CMD_OLD_ARCHIVE): Make sure they are used. * libltdl/config/ltmain.m4sh (func_mode_ar): Convert the filename of the archive to host format (MSYS fails to convert paths that are prefixed the -out: in arguments). Makes stresstest.at go a bit further on MSYS/MSVC. 2009-01-31 Peter Rosin ... Add func_to_tool_path. * libltdl/config/ltmain.m4sh (func_to_tool_path): New function. * libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): Add libtool variable $to_tool_path_cmd, and AC_SUBST it. * Makefile.am: Ensure to_tool_path_cmd is included in TEST_ENVIRONMENT so that it is passed to (old testsuite) tests. * tests/testsuite.at: Ensure to_tool_path_cmd is passed as a variable setting on the configure line for (new testsuite) tests. 2008-11-24 Peter Rosin ... Make preloading heed libname_spec. * libltdl/ltdl.c (libprefix): New static variable describing the prefix of static archives. (try_dlopen): Use libprefix. * libltdl/m4/ltdl.m4 (_LTDL_SETUP): Export prefix of static archives to config.h. 2009-01-26 Peter Rosin ... Add lib prefix to archive name if needed in symbol list. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): When lib prefix is required, add it - if needed - to the module name as well to match what is done to the symbol that is looked up. 2009-01-26 Peter Rosin ... Don't settle for any dumpbin/link program as name lister. * libltdl/m4/libtool.m4 (LT_PATH_NM): When locating dumpbin or link -dump, check if they appear to really be capable of name listing, in order to eliminate e.g. link from coreutils. This makes the name lister decision fall back on nm as the default if no acceptable candidate is found. * THANKS: Update Reports by Rudolf Leitgeb and Peter Kjellerstedt. 2009-02-17 Charles Wilson ... Document and test LT_DEBUGWRAPPER cwrapper macro * tests/cwrapper.test: Add new test for -DLT_DEBUGWRAPPER. * doc/libtool.texi [Linking executables]: Mention wrapper executables, in addition to wrapper scripts. Add menu referencing subsection 'Wrapper executables for programs'. [Wrapper
