Re: [RFT PATCH v4 0/8] Sysroot series

[Charles Wilson]

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