This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]

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:

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

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

> 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 WHAT if there are two copies of *possibly
> different* versions of (ditto w32api...).  At least I know that
> /usr/share/info/ is always in sync with /usr/bin/gcc, and
> /usr/$target/share/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, and the native cygwin one...ALL of which may be
> at different minor version levels (*), which version does
> /usr/share/info/ match?
> Just one of them.
> That sux. How can I RTFM if my FM doesn't match my FCompiler? :-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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]