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
