libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI: latest "official" cygwin libtool


From: Peter Rosin
Subject: Re: FYI: latest "official" cygwin libtool
Date: Tue, 24 Feb 2009 23:22:03 +0100
User-agent: Thunderbird 2.0.0.19 (Windows/20081209)

Den 2009-02-24 04:04 skrev Charles Wilson:
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.

Hi Chuck,

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? 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...

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

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?

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].

And the 07- patch seems to break ordinary crosses. 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
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. 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

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.

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.

Cheers,
Peter

(sha1-ids from my git-preview of pr-msvc-support + more patches)

[1] Allow Microsoft lib to be used as the archiver.
    0bb52ed03e71109ef75f8d72439ea1365ae14f42
[2] libtool-ar.patch
    8c17887ee34e73a2aeb127b94f5b76f45dc34017
[3] Use LT_AR internally and convert archive file to host format
    4b4be9916e5f58b1c87c24e77a32b19521d5933b
[4] http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00050.html




reply via email to

[Prev in Thread] Current Thread [Next in Thread]