This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: RFC: cygport cross-compiling APIs
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.
> No argument from me. There will be weeping, wailing, and gnashing of
> teeth on the list, tho.
What else is new?
> 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. 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.
> > BTW, weren't you going to check mingw.org gcc for patches and options so
> > I could cook up .cygport drafts for those as well?
>
> See attached. Short version: no patches to the source code, but some
> odd build techniques.
>
> One thing we probably don't care about: mingw.org uses a "forward.c" app
> to emulate hardlinks (and to avoid MSYS's fallback of "make a separate
> copy" for symlinks) of very large .exe's.
>
> configure options:
>
> cd $builddir &&
> $srcdir/configure \
> --enable-languages=c,c++,ada,fortran,objc,obj-c++ \
> --disable-sjlj-exceptions \
> --with-dwarf2 \
> --enable-shared \
> --enable-libgomp \
> --disable-win32-registry \
> --enable-libstdcxx-debug \
> --enable-version-specific-runtime-libs \
> --disable-werror \
> --build=mingw32 \
> --prefix=/mingw
>
> Java is not yet ready, but is promised for later. Werror is disabled
> because there are some unaviodable warnings in the Ada build.
Does anyone actually *use* Ada? (/me promptly ducks.)
> 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.
> 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. That's
IMO not within the realm of the *Cygwin* distribution, nor should it be.
> 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...
... 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.
Sorry, but no thanks. MinGW's place within the distro should be for
cross-compiling.
> Well, it does appear that we are at loggerheads. You insist that
> cygwin/mingw is EXACTLY the same as linux/mingw or solaris/irix or any
> other combination; I say there is a significant difference between
> cygwin/mingw and any other host/target combination, and that difference
> makes it wise for use to make certain, minor, accommodations.
>
> Like, for instance, simply splitting runtime DLLs -- even i686-mingw32
> or x86_64-mingw32 ones -- into separate installable packages JUST LIKE
> we do for native cygwin DLLs. I simply can't believe you're digging
> your heels in over two lines of cygport(5) code and an extra .hint file
> -- simply for the sake of treating a cygwin-hosted mingw compiler
> EXACTLY like a linux-hosted one.
>
> cygwin != linux -- *especially* when it comes to runtime interactions
> with win32.
>From the website: "Cygwin is a Linux-like environment for Windows."
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.
> 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. My views on
packaging come from a bigger picture, based managing thousands of
packages over years, together with observing how other distros do
things.
I suppose we'll need cgf and Corinna's opinion on this one.
Yaakov