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

[Ralf Wildenhues]

Hi Charles,

* Charles Wilson wrote on Tue, Aug 03, 2010 at 07:22:46AM CEST:
> 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.

Sorry, but I don't think that is viable.  Say, C:/mingw is owned by the
administrator, but D:/mingw is domain of user A.  Starting your app on
D: as user B makes B susceptible to files which A owns.  In general, you
cannot leave away the drive letter when specifying the --prefix.

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

Sure.  I don't disagree with leaving the sysroot part out of --prefix.

> 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 guess what I don't see is why the former case doesn't also use
  --prefix=C:/MinGW

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

Ahh.

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

Is this still relevant in light of my above reply?

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

Please allow me to give a sort-of simple-minded answer, hope I can make
the gist of it clear:

If Libtool gains the --with-sysroot feature, then that should be tested
as part of the Libtool testsuite.  Currently these tests all skip if the
compiler found is not GCC or has not been configured with a sysroot.
These two side-conditions mean that when I run the testsuite on all the
systems and in all the configurations that I have been testing
prereleases in the past, *none* of them will actually cover any of the
new sysroot functionality, because even the cross compilers that I test
do not use a sysroot.

Given the experience that new Libtool tests need on the average about
three or more iterations to get right portably, this makes me a bit
nervous.  We should really, really try to get test coverage high for
this feature on as many setups as possible.

If there is anything in Automake that isn't working for this kind of
test, well, then let's not use automake for this part of the Libtool
testsuite.  We've been avoiding it in most of the new testsuite already
anyway.

Thanks,
Ralf