Re: FYI: latest "official" cygwin libtool

[Charles Wilson]

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