Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]

["Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>]

On Thu, 2010-07-08 at 10:34 -0400, Charles Wilson wrote:
> Unless Corinna/cgf really put their foot down and forbid multilib, I
> think we should defer to whatever JonY wants to do.
> 
> Now, his ORIGINAL proposal was 64bit only, non-multilib.  Maybe he'd be
> pleased to go back to that; my feeling is he'd rather do multilib if
> possible, but I'm not sure, and certainly don't speak for him.

Right now I'm working with non-multilib, both i686 and x86_64.  It's a
lot cleaner that way -- especially when it comes to cross-compiling
other packages, doing so in a simultaneous multilib fashion would
require even more drastic changes to cygport.

> Remember, here's the fedora-mingw filesystem that was the motivating idea:
> http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout

Now *this* changes the discussion entirely.  I was unaware of this
feature, but now I see that using GCC sysroots solves a lot of problems
I was anticipating:

1) using a pre-built target-compiled package is as simple as unpacking
it under /usr/$target/sys-root

2) Installing an entire cross-compiled package
under /usr/$target/sys-root is a  whole lot easier than trying to force
use of /usr/$target/{include,lib} and deciding what else to leave out.

3) With sysroot, cross-compiled packages don't have /usr/$target
hard-coded into the binaries or .pc and .la files, so they will work as
is on either their $host system or under the sysroot without path
mangling.

I'm going to proceed along these lines.  /me rebuilds everything again
for umpteenth time.

> Well, sure, my normal cygwin $PATH wouldn't include
>   /usr/sysroot/$target-shortname/bin
> as a routine matter.  I said I want to be able to set it, temporarily
> and as necessary, for testing.

You mean /usr/$target/sys-root/$prefix/bin; that's where (non-deep)
mingw* dlls would land anyway with libtool's ../bin logic, so there they
would stay.  The only catches are 1) fixing deep non-module libs for
sys-root, and 2) relocating the gcc libs, which the Fedora packages do
put in the sysroot (but don't fixup the gcc .la's).  The latter will
take some more work.

> Maybe I'd also have a batch file that starts up a cmd.exe window, with
> no cygwin in sight, but with $PATH set to
> C:/cygwin/usr/sysroot/mingw32/bin if I want to use some custom
> mingw32-ish tool I've built. And it ought to be able to "find" all of
> its DLLs...

That would be the natural result of using a sysroot, pending the issues
above.

> Yaakov, the more I think about it, the more I believe that there really
> should be two different cygclasses here:
> 
> cross-toolchain.cygclass
>    + maybe a modification/extension, mingw-cross-toolchain.cygclass
> 
> for controlling how cygport builds packages that are PART of a cross
> toolchain: e.g. binutils and gcc.
> 
> and
> 
> cross.cygchain
> 
> for controlling how packages that themselves are NOT intrinsic parts of
> the toolchain, like mingw-xz.

You may be right; otherwise you have a dual-personality cygclass to
handle both and, given the other internal changes necessary to
accommodate cross-compiling, treating them separately is probably
simpler.  Why do you think mingw*-binutils/gcc need to be handled
differently than other toolchains?

> Not sure if (mingw-runtime, w32api)|(mingw64-crt-lib, mingw64-crt-headers)
> belongs in this category, or the previous one.  Probably this one.

Yes, I think so.

> I really just don't understand this obsession with saving a few
> kilobytes of disk space...so WHAT if there are two copies of *possibly
> different* versions of gcc.info (ditto w32api...).  At least I know that
> /usr/share/info/gcc.info is always in sync with /usr/bin/gcc, and
> /usr/$target/share/info/gcc.info is in sync with /usr/$target/bin/gcc.

info(1) won't find it there, so I don't see much point in that.

> If I have four different gcc compilers (three cross, mingw64,
> mingw64-32, mingw.org) and the native cygwin one...ALL of which may be
> at different minor version levels (*), which version does
> /usr/share/info/gcc.info match?
> 
> Just one of them.
> 
> That sux. How can I RTFM if my FM doesn't match my FCompiler?

http://lmgtfy.com/?q=gcc+manual&l=1 :-D

> But if the version of the various compilers differ -- and they will,
> especially if users are allowed to choose prev: or test: versions of
> either compiler -- then the ONLY way to ensure the correct i18n files
> are used is to configure with a custom --datarootdir, regardless of what
> you do with the options controlling directories under it, like --docdir
> and --mandir (there is no such thing as --localedir, so you can't
> specifically relocate it by itself).
> 
> Or turn off i18n, which is definitely suboptimal.

I think we understand now why the distros do just that:
$target-prefixing the textdomain is impractical, relying on concurrent
versions is unrealistic, and /usr/$target/share is not meant to exist.
Besides which, binutils and gcc don't have our latest (patched?) gettext
macros, so they result in LIBINTL=/usr/lib/libintl.a, and their build
systems leave no way to override that static linkage.  Doing the
autoreconf dance with these is no simple matter either.  So while I
agree it's suboptimal, unfortunately for now I think we may need to go
that way as well.

> But if you want those fixups to behave differently for one class of
> cygports compared to another -- I know you don't currently believe this
> is necessary, but assume it is for the sake of argument -- how to you
> impose that distinction, from the .cygport(5) level?

You won't, it will be handled internally.


Yaakov