RFC: cygport cross-compiling APIs

[Charles Wilson]

On 7/13/2010 1:36 AM, Yaakov (Cygwin/X) wrote:
> On Mon, 2010-07-12 at 22:45 -0400, Charles Wilson wrote:
>> I don't really care either way about that one.  What about things
>> associated with $sysconfdir and $localstatedir?  (e.g. /etc and /var are
>> usually "outside" of $prefix).  For cross (clients), suppress
>> prep_etc_defaults, and assume $sysconfdir and $localstatedir are
>> underneath $prefix?
> 
> IIUC /etc and /var only belong outside of $prefix when $prefix == /usr.
> Any other $prefix and they go back underneath, so that's what I'm doing.

That's what I figured.

>> Hm. A 64bit version of setup.exe; interesting. I don't mind providing
>> the additional packages for that; the list of setup's dependencies isn't
>> THAT long.
> 
> No, I said i686-mingw64.

You're right; I misread.

> I easily cross-built setup's deps for that
> toolchain then tried to build setup, but the mingw64 DDK headers are
> clearly not up to the task; they #include headers which do not exist and
> apparently some headers are missing.  setup.exe needed some adjustments
> as well even as far as I did get.  To be continued.

There is an "add-on" component that can be treated as part of the
mingw64-crt-* build. You download it separately from reactos or wine, I
don't remember, drop it in (a specific) place, and THEN configure and
compile.

Anyway, I wonder if the "missing" files are expected as part of this add-on?

>> Technically, the mingw.org folks say the only cross compilers they
>> support are ones built using this tool:
>>
>> http://sourceforge.net/projects/mingw/files/Cross-Hosted%20MinGW%20Build%20Tool/x86-mingw32-build-1.0.1-rc1/x86-mingw32-build-1.0.1-sh.tar.bz2/download
>>
>> but...we probably would provide support for "our" cross compiler right
>> here, anyway. And we can probably coordinate "our" build closely enough
>> with the mingw.org folks that they would likely "bless" our version, too.
> 
> We should definitely be coordinating patches and configure options so
> that our compiler is actually compatible to theirs.  Whether or not they
> "bless" is up to them.

Oddly, I'm not at all sure that the native mingw.org gcc-4.5.0 is
identical to the cross-built one generated by this script.  For
instance, the cross script ensures that the target libs are built using
-mms-bitfields. It's not clear to me that the native one does that,
unless it happens automatically.

So...they (may) have their own issues, in that regard...

>> E.g. I want to have a package:
>>
>> chucks-tools-VER-REL that has
>> requires: mingw64-i686-libstdc++6
>>
>> Why is this verboten, when all it takes is a little cygport magic no
>> different that any of our other 500 native cygwin packages, or your
>> other 2000 cygwin ports packages?
> 
> IOW you want to make a mingw mini-distro driven by setup.exe.

No, I want to locally extend my team's toolkit, currently based on
cygwin, by providing a few local native tools they can install within
that same cygwin core installation.

This is not a mingw distro.

> That's
> IMO not within the realm of the *Cygwin* distribution, nor should it be.

And naturally these extensions would be inappropriate to ITP, so I'm not
trying to add them to Cygwin's actual distribution.

>> Again, this boils right back down to the fact that here, our Host
>> platform can simultaneously execute applications (and libraries) from
>> both the $host and the $target.
> 
> So therefore we should change the distro into some Cygwin/MinGW hybrid
> where anything goes as long as it's PE?  So why not put the DLLs
> in /usr/bin?  Hey, throw in DJGPP while you're at it.  You could even
> convince GCC to treat them all like a m32/m64 multilib...

Now you're just setting up a strawman, and not doing a very good job of
it, either.

I never said anything like that.  ALL I'm saying is that I think we
ought to split out the gcc language runtime DLLs into separate packages,
JUST like we do for every OTHER DLL in the entire distro.  And
furthermore, for those cross-compiled packages that are ALREADY part of
the distro, and which ALREADY split the DLLs into separate packages,
that they should continue to do so.

Nothing more.

And I never suggested anything like "Cygwin/MinGW hybrid anything goes
as long as it's PE"; nor did I ONCE in thousands of words in these
related threads suggest that mingw DLLs should go in /usr/bin (except
maybe mingwm10.dll 'cause it's already there, but I wouldn't mind its
disappearance either).

Argue against what I actually said, not some strawman creation of your own.

> ... Wait, sound familiar?  It was called "-mno-cygwin".  Yes, we used to
> do just that, and IT DIDN'T WORK.  And even worse, people got confused.
> So now we're moving *away* from that, and for good reason.

No, what I actually said doesn't sound anything like -mno-cygwin.

Jeez. How you get there from a simple discussion about whether
libgcc-1-sjlj.dll goes into its own package, or gets folded into the
main cross-gcc package...is a mystery beyond mortal ken.

> Sorry, but no thanks.  MinGW's place within the distro should be for
> cross-compiling.

Well, hell's bells, I suppose we shouldn't include any of the actual
RESULTS of cross compiling at all.

I'll just mosey over to sourceware and delete mingw-zlib, mingw-bzip2,
mingw-libgpg-error, mingw-libgcrypt, and mingw-xz then.

After all, they are not part of the actual mechanics of cross-compiling,
are they?  People should just USE the MinGW cross tools we provide and
always compile everything from scratch.  Because there's no place for
MinGW stuff except the cross compiler itself within cygwin.

That's ridiculous. (Now THAT's how you do strawmen!)

>> cygwin != linux -- *especially* when it comes to runtime interactions
>> with win32.
> 
> From the website: "Cygwin is a Linux-like environment for Windows."

Linux-like.

Not a linux clone. Otherwise, we should remove /proc/registry.  And
regtool. And cygrunsrv.

> The point is that Cygwin should strive to be like Linux wherever
> possible.  Focusing on running MinGW instead of building it is doing the
> exact opposite.

BS.

We are ALREADY providing all of the necessary items, in exactly the
necessary location to allow "mingw" items to execute from within
sys-root. You are attempting to enforce your idea of the "proper" use of
cygwin by unnecessarily bundling an 84k DLL into a 12MB toolchain, so
that only *developers* using mingw-gcc are "allowed" to execute
cross-compiled tools installed within sys-root.

But those lesser mortals who don't actually compile those apps
themselves are not allowed to execute them within sys-root, unless they
download 11.9MB of crap they don't need.

Maybe we should just switch cygwin over to a pure gentoo ebuild system,
since we are apparently required to hate people who don't compile
everything for themselves.

I don't have the words...and THAT's saying something.

>> Fortunately, I don't have to convince you of this; I only have to
>> convince JonY of the utility of splitting the language runtime DLLs into
>> separate packages.  That's purely the decision of the maintainer, and
>> how he writes the final cygport(5) and has little to do with the
>> cygport(1) script.
> 
> That's the unfortunate result of having few, if any, policies wrt to
> packaging; everyone just does whatever they want, and as a result we
> have almost no consistency or adhesiveness in the distro.

No, that's called freedom -- and, surprising as it may seem, not
everyone agrees with you in every particular.  You are not Linus -- and
not even he gets to dictate how Red Hat assembles their distro.

> My views on
> packaging come from a bigger picture, based managing thousands of
> packages over years, together with observing how other distros do
> things.

No, you don't get to play that game with *me*.  Suffice it to say that
my experience is even more long-term, and just as extensive, and my
opinions are JUST as valid as yours.

> I suppose we'll need cgf and Corinna's opinion on this one.

Right. I can see it now:


Contrary to all prior and existing examples, for cross-compiled packages
for $host mingw, and cross compilers $targeting mingw, we will not
accept ITPs in which the the relevant DLLs have been placed in separate
tarballs.  Also, existing cross-compiled packages must be repackaged to
meet the new guidelines.  No matter what the poor sap volunteering to
actually do the work wants, or has done historically with pre-existing
packages like mingw-xz.

Because We Control The Horizontal And The Vertical, and We Have Decided.


And this sudden and radical departure from the current relatively
laissez-faire regime of ITPs is necessary because...Yaakov thinks
putting *some* DLLs into separate packages is icky.  But not *other* DLLs.

--
Chuck