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

[Ralf Wildenhues]

* Charles Wilson wrote on Fri, Aug 06, 2010 at 03:26:30AM CEST:
> But a STEP in that direction is to reduce the current pain experienced
> by cross compiles for $host=mingw even with --prefix=/unixish; pain
> caused by the current lack of sysroot support in libtool (and some other
> utilities).
> 
> But...mingw is not the only $host in the world; the pain in (c) is
> experienced right now by *all* cross users of libtool.  Other $hosts
> don't care about mingw's issues with X:/foo paths.  The only situations
> that matter to them are (b) and (c), and libtool's current lack of
> sysroot support makes (c) very painful.
> 
> Let's fix that, THEN worry about the screwball mingw platform's
> decade-festering issue with multiroot file systems.

OK.

> >> The only real solution, as I've said, is:
> >>
> >>   1) don't cross compile for $host=mingw. Ever. Always compile
> >>      natively, and use --prefix=X:/stuff WITH the drive letter.
> > 
> > We are at that position already, and would like to improve from there.
> 
> Well, we're a bit past THAT.  You can DO cross compiles with
> --prefix=/foo, even without sysroot support.  It's ugly, and you have to
> post-process the .la files and jump thru other hoops, but it can be done.

OK.

> With sysroot support in the (cross) compiler, AND sysroot support in
> libtool, it becomes possible to do it without jumping thru as many hoops.

Good.

> Honestly, this whole issue with DESTDIR, and X:/foo paths, is a
> *separate topic* and really doesn't belong in THIS discussion at all.

Fine with me.

> The only reason it came up is because *I'm* the one testing Paolo's
> patches, and *I* have a fistful of mingw-target cross compilers.  If I'd
> tested only with sun-, hpux-, and irix- cross compilers, none of this
> would ever have come up.

And it's great you're doing all the testing.  But honestly, unless you
keep doing that testing before every new release, things are going to
break in the future.  Which is why I am harping so much on tests that
run as automatically as possible.

> > Relocatability is one possibility, and one that I think we should
> > expore eventually, because it is a conceptually good idea.
> 
> Well, there is a set of tools for it in gnulib, but it requires EVERY
> library in your system to adopt it, really.  Plus the program component
> is GPL, which limits acceptance -- especially if you want it to become
> universal.

Well, yes, let's not further discuss this topic now.  The system in
gnulib is not the end of the story, and the technical issues can be
addressed in a different way as well.

> The discussion of semantics, when you start talking about how and
> whether DESTDIR is supported, is a distraction from the sysroot support.
> I'd rather drop all discussion of mingw since sysroot is useful and
> needed for cross compilers that target other $hosts.

OK.

> > So I really hope that my comments don't discourage you from working on
> > this.  You guys have done a great job so far, and I'm really trying to
> > not delay review; it would be sad to see this not fly just because we
> > talk past each other about some related questions.
> 
> I'm encouraged by the review. I'm discouraged by the rabbit trails
> eating up scarce time and resources (and I consider tilting at the
> longstanding DESTDIR+win32 windmill a rabbit trail).  It is what it is.
>  If it is to be fixed, it's not part of *this* patch, and shouldn't
> complicate consideration of *this* change.

OK.

> > What if we special-cased drive letters in the way that
> >   DESTDIR=C:/foo/bar prefix=D:/baz/zork
> > 
> > gets mapped to
> >   C:/foo/bar/D/baz/zork
> > 
> 
> Well, I can easily do that as follows:
>   make install prefix=/D/baz/zork DESTDIR=C:/foo/bar
> 
> but what does that BUY me?
[... snip good explanation ...]

> Why are we considering this again?  And if we must, can we put it off to
> another thread, and keep our focus on Paolo's actual patch for sysroot
> support, and not hypothetical fixes for DESTDIR+mingw?

OK.

> >> $ gcc --sysroot=/bob -print-sysroot
> >> /bob
> >>
> >> So, you could easily create a test that uses the native system compiler
> >> to "fake" a cross-toolchain "sysroot" test.
> > 
> > Exactly.  That's what I meant.
> ...
> > These parts are what I don't know, because I have no experience in this
> > area.  Is creating such a link farm feasible?  Presumably, some subtrees
> > could just be created with one symlink to a directory?  Presumably the
> > symlink-tree script from Automake/GCC could help?
> 
> Dunno. It's possible that all you really need from lib are elements in
> that directory alone, and no subs.  For include, though, who knows how
> ugly the #include chain could be, with sys/ and bits/ and sys/bits/ and
> sys/bits/$arch and all.  (Oh, and multilib: what about lib64?)

libtool is not known to install files itself below $includedir, so for
include, it would seem sufficient to simply 'ln -s' it when $build has
real symlinks, and skip the test if $build is w32.

Wrt. lib and lib32, lib64, can we find out all files GCC needs by asking
it several -print-* questions?  Plus maybe optimistically searching for
libc and ld*.so?

> > If such a test group proves to be very expensive, then I don't mind
> > disabling it by default; but just the fact that some automated way of
> > testing is fairly easily available, would be a big help.
> 
> Well, if it's an optional test, then it would be okay to rely on
> non-standard (but common) tools, right?  Because symlink-tree is taking
> over ten minutes to do my /usr/include, but lndir was less than 30 seconds.

Sure.  I really intend to only have a few dozen of those links at most,
though; hopefully.

Thanks,
Ralf