On 7/8/2010 3:22 AM, Corinna Vinschen wrote:
> On Jul 7 18:24, Christopher Faylor wrote:
>> [...]
>> Whether we use w32api in the cygwin tree or from somewhere else really
>> doesn't matter as long as Cygwin builds.
>
> That's why I'd like to know if Cygwin builds with w32api from the
> mingw64 project.
Have you checked with Red Hat's lawyers concerning the use of mingw64's
w32api to build their cygwin-based products?
> Even after a night's sleep I still don't like the idea to hvae two
> versions of w32api in the distro. To me, w32api belongs into
> /usr/include. One version for everybody. w32api is *not* cross
> compiler specific, it's a resource for all three targets, Cygwin as
> well as 32 bit and 64 bit Mingw.
Well, the 64bit build of w32api provides over 2000 import libraries. The
32bit build has only about 225. Apparently this is because the .def
files that each are generated from are maintained separately, vetted on
each system, and their contents *differ* on each system. Until recently,
mingw64 focused mainly on 64bit support; 32bit efforts are much younger
for them.
So while the include/ bits may be the same for mingw64's w32api between
32bit and 64bit systems, the lib/ bits definitely differ.
And, of course, they differ from the current cygwin/mingw.org 32bit
version -- but that's a lot easier to "fix" than the headers IMO. (.def
file contents don't appear to be as "difficult" to share between mingw64
and mingw.org, as far as this non-lawyer can tell. I mean, it's not
like anybody could "copy" the .def file contents from the Windows SDK,
so mingw.org doesn't need to worry about that).
> However, I won't object against having a version for the 64 bit gcc
> hidden in the cross-compiler tree, if there's no way around it.
> But *if* there's a way to keep just a single version, it should be
> exploited.
I don't get this. There are three reasons to be concerned about multiple
copies -- even if they are identical (which in this case they are not
and can't be, esp. 64bit vs 32bit implibs).
1) disk space
2) things that should be identical (like headers for the
OS's API) out of sync, or keeping them deliberately different
3) end user confusion
IMO (1) is a non-issue. If you're going to install a cross compiler,
some duplicated implibs and headers are the least of your concerns with
regards to disk space.
(2) -- well, if cygwin/Red Hat doesn't care about the "where did you get
that function declaration you mingw64 folks added to foo.h" problem,
then maybe the mingw64 w32api headers can be used by all of
(mingw64-32bit, mingw64-64bit, mingw.org-32bit, cygwin) compilers. But
the implibs will be distinct between the 64bit version and the 32bit
version(s). But...even given that, I still don't see a real problem.
Do we worry, when creating a sysroot for an embedded target on a linux
$host, when compiling zlib, that we have two copies of zlib.h -- one in
/usr/include, and another in
/usr/my-embedded-toolchain/sysroot/usr/include? Do we worry that there
are multiple copies of the glibc headers in both locations (or all of
them, if I have several cross compilers)? Even when I'm using exactly
the same version of glibc or zlib on both my development machine and the
target, so the headers are, in fact, identical?
No...that's just how cross compilers work! The sysroot for
cross-compiler target A will probably contain lots of similar stuff,
maybe even identical, to the sysroot for cross compiler target B, and
similar to the stuff in the $host's "sysroot" /.
(3) I think it's is hell of lot MORE confusing for our users, for us to
foist a regime on them that says "cross compilers should never access
stuff in the system include or lib directories; that's cross-compiler
101. Except, of course, for /usr/include/w32api and /usr/lib/w32api --
and we've either patched all of our mingw* cross compilers to look there
automatically behind your back in addition to its own sysroot, or you
are expected to manually add the appropriate and completely
non-intuitive -L/usr/lib/w32api -I/usr/include/w32api to your CROSS
CPPFLAGS/LDFLAGS when building.
Except for 64bit, where you should use -I/usr/include/w32api but not
-L/usr/include/w32api.
And never mind that that is completely DIFFERENT than how the same cross
compiler toolchain would operate over on any other $host, so we get FAQs
not just from total n00bs but also from people with lots of experience
using linux-$hosted cross compilers.
Ugh!
And that's not even going into the issue of how, exactly, we are to
'tease out' the w32api-related PARTS of mingw64's separate
mingw64-crt-include and mingw64-crt-lib trees, if we plan to share
mingw64's "w32api" between cygwin|mingw.org, and mingw64-32, but
(obviously) not the "crt/mingw-runtime" bits, as mingw64 has them all
jumbled together.
AND assuming you, and Red Hat, have no legal issues related to mingw64's
"w32api" headers + cygwin. It'd be great if those legal concerns ARE
unimportant, don't get me wrong. But I'd rather have a mingw.org
cross-compiler tomorrow, using mingw.org's w32api, AND a separate
mingw64-32 cross compiler using mingw64's "w32api", than wait six months
having neither while the legal beagles do their thing, And...we can
always, six months from now, "drop in" the mingw64 "w32api" as an update
to the mingw.org sysroot...
Given all of that, is multiple copies really THAT annoying?
--
Chuck
