This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 7/12/2010 1:49 AM, Yaakov (Cygwin/X) wrote:
> On Sun, 2010-07-11 at 14:43 -0400, Charles Wilson wrote:
>> However, it's easier to walk before you run, so how about we get
>> everything nice and pretty with two (three, counting 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, AFAICS they still ship gcc-3.4.4,
> which we (sort of) have already.

No, their current release is 4.5.0, and the previous release was 4.4.0.
They have had 'testing' releases of 4.3.0 and 4.2.1, but those never
achieved sufficient stability to be promoted as (what we would call)

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

Patches were required for 4.2.1 and 4.3.0.  However, I believe's 4.4.0 and 4.5.0 were based on upstream gcc sources without
modification, just configured for i686-pc-mingw32.  I'll d/l the -src
and check later.

And, of course,'s compilers are tied to the winsup/w32api
headers and libs, and to the winsup/mingw mingw-runtime.

>> [1] The official --prefix with which cross-compiled clients, built
>>     using the toolchain, should be configured.  Dunno whether
>>     this should be the /mingw (which is what uses for its
>>     stuff, modulo dosify concerns), or something we decide on our own,
>>     like --prefix=/mingw32 or --prefix=/
>> [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 (or, more accurately, they don't want to run the
>>     risk that stuff from 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*.

And that's specifically why mingw64 doesn't want to use it, AND why
*mingw64* recommends that, if you install multiple versions of the
(non-cross) mingw and/or mingw64 compilers, that NONE of them go into
/mingw (C:\MinGW, D:\MinGW, etc) -- because then ALL of them will find
whatever lucky version happens to get installed there.  (IIRC, they
acknowledge that you'd then have to specify explicitly -L and -I options
even for native compilers, but that's not an issue for us, right? For
cross-compilers, our users would have to do that anyway, correct?)

Obviously, this conflicts with **'s recommendations.

I don't know if this disagreement would affect our decisions, because
(a) all three toolchains would have different sysroots, so toolchain A's
"/mingw" sysroot $prefix would be at /usr/$target-A/sys-root/mingw,
while toolchain B's sysroot $prefix "/mingw" would be at
/usr/$target-B/sys-root/mingw -- so there would be no conflict.

However, if compiled clients were to be (re)packaged and installed by
third party users without cygwin...then they'd all "want" to go in
/mingw if all of our toolchains used .../sys-root/mingw.  And then we
run headlong into that mingw64/ disagreement. "compromise" was to follow's recs for the
toolchain, and mingw64's recs for theirs. (But I held out the
possibility, for, of specifically choosing a different sysroot
$prefix, such as /mingw32, instead -- just to avoid "privileging" one
toolchain over the others.)

Honestly, I think we just have to experiment to see which way works best
-- including *using* the toolchains to compile clients, and then install
the results on a virgin machine in various locations.

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

I was thinking of client packages that might not be fully 64bit ready;
e.g. some utility apps need to be compiled using -m32, but most of the
package is -m64-ready.

In this case, you'd want to configure using the 64bit toolchain, but set
a per-app CFLAGS that include -m32 for the few apps that aren't 64bit
ready. AFAIK, autotooled packages don't let you specify a per-target CC,
so you can't easily use a different (e.g. i686-*) compiler.

Now, I don't KNOW that any projects like this exist, but that was my
thinking in "favor" of a multilib 64bit toolchain.

But that's all an argument for later, AFTER we learn to walk.

>> Ah, but *I* know where it is, so I can at LEAST do
>>   info /usr/$target/share/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.

They'd be much more /likely/ to find it, than to find

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

They also don't change much between releases, so I've no heartburn about
that either.

>> The only relevant patch in "our" gettext's m4 macros is this:
> I was referring to shrext in config.rpath:
> Although now that I think about it, we could just manually patch that
> for each toolchain package.

Well, that, and the fact that the currently shipping cygwin gettext does
NOT patch config.rpath -- so until that changes, you'd have to manually
patch gcc's copy anyway.

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

D'oh.  Yeah, I was thinking only of the first argument, the domainname.
You're right.

> But even with --datarootdir=/usr/$target/share, somehow the locales
> *still* end up in /usr/share/locale. 

Probably some of the upper-level's don't pass datarootdir to
the subconfigures; or some of the lower-level's don't use
datarootdir. (If everything were automake'd, then neither issue would
occur; but IIRC there are some hand-rolled's in gcc)

This is likely a gcc build bug.

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

Incorrect translations are worse than missing ones, IMO.

> Now back to work on this...



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]