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
