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 Sun, 2010-07-11 at 14:43 -0400, Charles Wilson wrote:
> How about this: suppose for the sake of argument that JonY *really*
> would rather the 64bit compiler, at least, also support multilib -- in
> the long run.
> 
> However, it's easier to walk before you run, so how about we get
> everything nice and pretty with two (three, counting mingw.org) separate
> non-multilib tool chains.  Each would be built with sysroots, and given
> the way (I now discover) sysroots *must* work, we would thus end up with;

Since you keep mentioning mingw.org, AFAICS they still ship gcc-3.4.4,
which we (sort of) have already.  Is that what you are referring to, or
do you simply mean the latest binutils and gcc built for target
i686-pc-mingw32?  If the latter, are any patches or specific configure
options necessary (besides using dw2 exceptions instead of sjlj)?

> [1] The official --prefix with which cross-compiled clients, built
>     using the mingw.org toolchain, should be configured.  Dunno whether
>     this should be the /mingw (which is what mingw.org uses for its
>     stuff, modulo dosify concerns), or something we decide on our own,
>     like --prefix=/mingw32 or --prefix=/mingw.org.
> 
> [2] Whatever prefix we choose to assert that cross-compiled clients,
>     built using the 32bit-flavor mingw64 toolchain, should be
>     configured.  I think the mingw64 guys recommend using anything
>     EXCEPT /mingw -- because they don't want to conflict with stuff
>     from mingw.org (or, more accurately, they don't want to run the
>     risk that stuff from mingw.org would conflict with THEM)
> 
> [3] Whatever prefix we choose to assert that cross-compiled clients,
>     built using the 64bit-flavor mingw64 toolchains, should be
>     configured.  I'm partial to --prefix=/mingw64.

Are you sure about this?  The /mingw prefix is hard-coded into all
gcc/config/i386/t-mingw*.

> Naturally, cygport's cross{-client?}.cygclass would arrange that the
> actual install prefix would be
>    ${D}/usr/$target-triple/sys-root/$configured-prefix
> before packing up whatever's underneath ${D}.

Ack.

> Now, IF the supposition above (about JonY really wanting to provide
> multilib) is correct, then we can figure out how the -m32 mode of a
> *later* release of the mingw64-64bit compiler would work.  But...walk
> first, then run.
> 
> And maybe JonY doesn't even care much about multilib.

>From the POV of building other packages, trying to build any package
simultaneously for a multilib setup is a lot of work, and cygport is
certainly not up to that right now.  I think it should suffice if we
provide both i686 and x86_64 mingw64 compilers.

> (*) NOTE: I'm assuming that we would continue to use
> --enable-version-specific-runtime-libs.

Of course.

> Ah, but *I* know where it is, so I can at LEAST do
>   info /usr/$target/share/info/gcc.info
> 
> with any other plan, I can't locally check the documentation for my
> currently installed cross-compiler.

You might, but others likely will not.

To make it even more confusing, the man1 pages are $target-namespaced,
so they are safe in /usr/share/man/man1, but the man7 pages are not.
The latter have very little to do with the actual packages, however, so
I'm not concerned about removing those.

> The only relevant patch in "our" gettext's m4 macros is this:

I was referring to shrext in config.rpath:

http://www.cygwin.com/ml/cygwin/2008-04/msg00659.html

Although now that I think about it, we could just manually patch that
for each toolchain package.

> I see. Yes, we'd really want the (cross) gcc and binutils apps to link
> against their own internal libintl.a, since the internal one would have
> our custom --datarootdir definition, so that it would look in the
> "correct" place for the proper version of the i18n stuff.

Huh?  Customizing the location of locales doesn't require a different
libintl, you just need to make sure that the second argument to
bindtextdomain(3) is set correctly.  So if we want to "invent"
$prefix/$target/share for toolchain.cygclass packages, cygport just
needs to set --datarootdir accordingly.

But even with --datarootdir=/usr/$target/share, somehow the locales
*still* end up in /usr/share/locale.  Whether it's worth trying to rely
on the native binutils/gcc locales for at least partial translations
(--enable-nls then remove ${D}/usr/share/locale) or not (--disable-nls),
I suppose is debatable.

Now back to work on this...


Yaakov