On 8/2/2010 2:27 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Mon, Aug 02, 2010 at 08:00:47PM CEST:
>> On 8/2/2010 1:55 PM, Ralf Wildenhues wrote:
>>> What about the w32 users that use --prefix=C:/mingw and then cannot use
>>> DESTDIR because that will not concatenate?
>>
>> According to the GNU Standards, you can always do this after building:
>>
>> make prefix=/new/destdir/old-prefix
>>
>> And -- supposedly -- "/new/destdir" is not supposed to appear
>> anywhere in the installed files. So, if you're doing a cross build
>> for a mingw $host, you can do this:
>>
>> configure --prefix=C:/MinGW && make
>> make install --prefix=/tmp/dest/MinGW
>>
>> and create your installable tarball from /tmp/dest.
>
> So are you saying this works with this very patch series?
Well, it depends on what you mean by "works".
We have to make a distinction between (1) cross-compiled packages that
are intended to be deployed on $build, for further (cross) development,
and (2) packages that are intended to be deployed on $host, for actual
use or for further (native) development.
Ideally, there wouldn't be such a distinction, but I don't think the
software universe has evolved to that point yet, unfortunately. We can
get close however -- and this sysroot support in libtool is one means of
getting closer. (What that REALLY requires is total relocation support,
in all libraries, scripts, and configuration files.)
For instance, suppose I have a cross compiler for mingw whose sysroot is
/usr/i686-pc-mingw32/sys-root. Suppose I want to build the gtk2 stack,
for win32. Well, that means I need to build gettext, and libiconv, and
zlib, and libpng, and a dozen other libraries before I can build glib
and the core gtk2. And, as I build each one, I want to install them --
or their -devel components like headers and link libraries -- into my
cross sysroot on $build, so I can continue on to the next item in the
stack. That's case (1); I'd build these with --prefix=/mingw, because I
WANT them to end up in
/usr/i686-pc-mingw32/sys-root/mingw
Now, since I've used --prefix=/mingw and NOT
--prefix=/usr/i686-pc-mingw32/sys-root/mingw, I can "cheat" even on
win32. I can take the binary runtime components -- even the -devel
components! -- and install them in
C: (or D: or E:)
and they'll end up under
C:/mingw
D:/mingw
or whathaveyou. Thanks to a quirk in window's path resolution, any
unixish absolute path is interpreted as if it were a path from the drive
root of the CWD. So, if CWD is on C:, then /mingw/libexec is
interpreted as C:/mingw/libexec. Since ALL the unixish paths will start
with /mingw, this will Do The Right Thing. If the elements had been
compiled with --prefix=$sysroot/mingw, then I could not do this, because
the embedded paths hardcoded into the binaries, .la files, and scripts
would all say things like /usr/i686-pc-mingw32/sys-root/mingw/lib, which
windows would transliterate into
C:/usr/i686-pc-mingw32/sys-root/mingw/lib, when what I REALLY wanted all
along was C:/mingw/lib.
So, this new scheme (where libtool supports --with-sysroot, and you
configure with --prefix=/mingw, but install using DESTDIR=$sysroot)
appears to work pretty well, and is only really possible with true
sysroot support in the toolchain and the configuration tools (e.g.
libtool, pkgconfig, and foo-config scripts). Call it case (1.5): built
on $build for developmental use on $build, but transplantable with maybe
only a few hiccups to $host for runtime and maybe developmental use.
However, items built for case (2) -- direct deployment on the $host (or
compiled "natively" ON the mingw host, that is MSYS/MinGW) -- are by
convention configured as:
configure --prefix=`cd /mingw && pwd -W`
which ends up as
configure --prefix=C:/MinGW
and the installation is usually preformed as
make install prefix=/tmp/something/MinGW
I did test that *libtool* itself, when configured and installed in this
way, does the right thing(s) for itself. That is libltdl-7.dll ends up
in the right place, the .la file has the right paths, etc. THAT's what
I meant when I said I tested this workflow with libtool. But honestly,
that's not really new; this is the way ALL of the mingw.org
natively-built (MSYS/MinGW) packages have been built, installed, and
packaged, for years now. What was NEW was that I ALSO tested this
behavior from a cross toolchain, where libtool itself was built,
configured, tmp-installed, and packaged for $host deployment as above,
using a cross $build environment.
Anyway, this workflow ensures that the actual, DOS-ish paths are
embedded anywhere such things are hardcoded, which is both good and bad.
But it also ensures that there IS no concatenation of paths that might
start with X:, since we replace the ENTIRE prefix with a unixish one
during make install. This technique works, even today on cross setups,
if you build one package at a time for deployment on $host. But you
can't easily do a "chain" of such builds on a cross system, without
effort. You sorta have to do twice the builds: one of type (1) and one
of type (2), for each library in the chain:
a) zlib class (1) installed on $build in sysroot under $prefix
b) zlib class (2) installed on $host under $prefix
c) libpng class (1) installed on $build in sysroot under $prefix
this will link against the libz.dll.a from (a). If you have
support on $build for running $host binaries (wine?) then at
runtime it would use the libz-1.dll from (a) as well.
d) libpng class (2) installed on $host under $prefix
this will link against libz.dll.a from (a)!!! However, once
installed on $host, it will RUN against zlib-1.dll from (b).
and so on, and so on.
Using method (2) alone would not yet be appropriate for a case (1)
installation (e.g. into a cross $build system's sysroot), because then
you WOULD be concatenating a unixish sysroot with a dosish "prefix".
(e.g. you can't really use (b) and install it on $build in sysroot, and
pretend that's a suitable replacement for (a); ditto (d) vs. (c)).
> If yes, then
> very cool, and I'd very much like this to be exposed in the testsuite
> (only on w32 systems, of course, and the C:/... path should be something
> unlikely to clash with any actual user files, in case make install does
> write there after all).
I'm not entirely sure what you want to test here -- or that it would be
something that *libtool's* testsuite should cover (wouldn't it be more
appropriate as part of automake's?)
--
Chuck
