cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]
Yaakov (Cygwin/X)
yselkowitz@users.sourceforge.net
Sat Jul 10 01:15:00 GMT 2010
On Thu, 2010-07-08 at 10:34 -0400, Charles Wilson wrote:
> Unless Corinna/cgf really put their foot down and forbid multilib, I
> think we should defer to whatever JonY wants to do.
>
> Now, his ORIGINAL proposal was 64bit only, non-multilib. Maybe he'd be
> pleased to go back to that; my feeling is he'd rather do multilib if
> possible, but I'm not sure, and certainly don't speak for him.
Right now I'm working with non-multilib, both i686 and x86_64. It's a
lot cleaner that way -- especially when it comes to cross-compiling
other packages, doing so in a simultaneous multilib fashion would
require even more drastic changes to cygport.
> Remember, here's the fedora-mingw filesystem that was the motivating idea:
> http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout
Now *this* changes the discussion entirely. I was unaware of this
feature, but now I see that using GCC sysroots solves a lot of problems
I was anticipating:
1) using a pre-built target-compiled package is as simple as unpacking
it under /usr/$target/sys-root
2) Installing an entire cross-compiled package
under /usr/$target/sys-root is a whole lot easier than trying to force
use of /usr/$target/{include,lib} and deciding what else to leave out.
3) With sysroot, cross-compiled packages don't have /usr/$target
hard-coded into the binaries or .pc and .la files, so they will work as
is on either their $host system or under the sysroot without path
mangling.
I'm going to proceed along these lines. /me rebuilds everything again
for umpteenth time.
> Well, sure, my normal cygwin $PATH wouldn't include
> /usr/sysroot/$target-shortname/bin
> as a routine matter. I said I want to be able to set it, temporarily
> and as necessary, for testing.
You mean /usr/$target/sys-root/$prefix/bin; that's where (non-deep)
mingw* dlls would land anyway with libtool's ../bin logic, so there they
would stay. The only catches are 1) fixing deep non-module libs for
sys-root, and 2) relocating the gcc libs, which the Fedora packages do
put in the sysroot (but don't fixup the gcc .la's). The latter will
take some more work.
> Maybe I'd also have a batch file that starts up a cmd.exe window, with
> no cygwin in sight, but with $PATH set to
> C:/cygwin/usr/sysroot/mingw32/bin if I want to use some custom
> mingw32-ish tool I've built. And it ought to be able to "find" all of
> its DLLs...
That would be the natural result of using a sysroot, pending the issues
above.
> Yaakov, the more I think about it, the more I believe that there really
> should be two different cygclasses here:
>
> cross-toolchain.cygclass
> + maybe a modification/extension, mingw-cross-toolchain.cygclass
>
> for controlling how cygport builds packages that are PART of a cross
> toolchain: e.g. binutils and gcc.
>
> and
>
> cross.cygchain
>
> for controlling how packages that themselves are NOT intrinsic parts of
> the toolchain, like mingw-xz.
You may be right; otherwise you have a dual-personality cygclass to
handle both and, given the other internal changes necessary to
accommodate cross-compiling, treating them separately is probably
simpler. Why do you think mingw*-binutils/gcc need to be handled
differently than other toolchains?
> Not sure if (mingw-runtime, w32api)|(mingw64-crt-lib, mingw64-crt-headers)
> belongs in this category, or the previous one. Probably this one.
Yes, I think so.
> I really just don't understand this obsession with saving a few
> kilobytes of disk space...so WHAT if there are two copies of *possibly
> different* versions of gcc.info (ditto w32api...). At least I know that
> /usr/share/info/gcc.info is always in sync with /usr/bin/gcc, and
> /usr/$target/share/info/gcc.info is in sync with /usr/$target/bin/gcc.
info(1) won't find it there, so I don't see much point in that.
> If I have four different gcc compilers (three cross, mingw64,
> mingw64-32, mingw.org) and the native cygwin one...ALL of which may be
> at different minor version levels (*), which version does
> /usr/share/info/gcc.info match?
>
> Just one of them.
>
> That sux. How can I RTFM if my FM doesn't match my FCompiler?
http://lmgtfy.com/?q=gcc+manual&l=1 :-D
> But if the version of the various compilers differ -- and they will,
> especially if users are allowed to choose prev: or test: versions of
> either compiler -- then the ONLY way to ensure the correct i18n files
> are used is to configure with a custom --datarootdir, regardless of what
> you do with the options controlling directories under it, like --docdir
> and --mandir (there is no such thing as --localedir, so you can't
> specifically relocate it by itself).
>
> Or turn off i18n, which is definitely suboptimal.
I think we understand now why the distros do just that:
$target-prefixing the textdomain is impractical, relying on concurrent
versions is unrealistic, and /usr/$target/share is not meant to exist.
Besides which, binutils and gcc don't have our latest (patched?) gettext
macros, so they result in LIBINTL=/usr/lib/libintl.a, and their build
systems leave no way to override that static linkage. Doing the
autoreconf dance with these is no simple matter either. So while I
agree it's suboptimal, unfortunately for now I think we may need to go
that way as well.
> But if you want those fixups to behave differently for one class of
> cygports compared to another -- I know you don't currently believe this
> is necessary, but assume it is for the sake of argument -- how to you
> impose that distinction, from the .cygport(5) level?
You won't, it will be handled internally.
Yaakov
More information about the Cygwin-apps
mailing list