On 7/9/2010 9:08 PM, Yaakov (Cygwin/X) wrote:
> On Thu, 2010-07-08 at 10:34 -0400, Charles Wilson wrote:
>> 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.
Hmm.
How about this: suppose for the sake of argument that JonY *really*
would rather the 64bit compiler, at least, also support multilib -- in
the long run.
However, it's easier to walk before you run, so how about we get
everything nice and pretty with two (three, counting mingw.org) separate
non-multilib tool chains. Each would be built with sysroots, and given
the way (I now discover) sysroots *must* work, we would thus end up with;
[root]
+- usr
|
+- bin - Links to cross compiler toolchain
| |
| +- i686-pc-mingw32-cpp \
| +- i686-pc-mingw32-gcc }-- mingw.org 32 bit
| +- i686-pc-mingw32-g++ /
|
| +- i686-w64-mingw32-cpp \
| +- i686-w64-mingw32-gcc }-- mingw64 32 bit ONLY
| +- i686-w64-mingw32-g++ /
|
| +- x86_64-w64-mingw32-cpp \
| +- x86_64-w64-mingw32-gcc }-- mingw64 64 bit ONLY
| +- x86_64-w64-mingw32-g++ /
|
+- i686-pc-mingw32 (mingw32.org stuff)
| |
| +- bin - Cross compiler toolchain
| | |
| | +- cpp
| | +- gcc
| | +- g++
| | +- ... etc ...
| |
| +- lib - Cross compiler toolchain support libraries / files
| |
| +- sys-root - root for cross compiled binaries
| |
| +- mingw [1]
| |
| +- bin - cross-compiled binaries & runtime DLL
| +- doc - documentation
| +- include - include files for cross compiled libs
| +- lib - cross-compiled static and link libraries
| | |
| | +- pkgconfig
| |
| +- share
| |
| +- man
|
+- i686-w64-mingw32 (mingw64 32-bit stuff)
| |
| +- bin - Cross compiler toolchain
| | |
| | +- cpp
| | +- gcc
| | +- g++
| | +- ... etc ...
| |
| +- lib - Cross compiler toolchain support libraries / files
| |
| +- sys-root - root for cross compiled binaries
| |
| +- mingw64-32 [2]
| |
| +- bin - cross-compiled binaries & runtime DLL
| +- doc - documentation
| +- include - include files for cross compiled libs
| +- lib - cross-compiled static and link libraries
| | |
| | +- pkgconfig
| |
| +- share
| |
| +- man
|
+- x86_64-w64-mingw32 (mingw64 64bit stuff)
|
+- bin - Cross compiler toolchain
| |
| +- cpp
| +- gcc
| +- g++
| +- ... etc ...
|
+- lib - Cross compiler toolchain support libraries / files
|
+- sys-root - root for cross compiled binaries
|
+- mingw64 [3]
|
+- bin - cross-compiled binaries & runtime DLL
+- doc - documentation
+- include - include files for cross compiled libs
+- lib - cross-compiled static and link libraries
| |
| +- pkgconfig
|
+- share
|
+- man
[1] The official --prefix with which cross-compiled clients, built
using the mingw.org toolchain, should be configured. Dunno whether
this should be the /mingw (which is what mingw.org uses for its
stuff, modulo dosify concerns), or something we decide on our own,
like --prefix=/mingw32 or --prefix=/mingw.org.
[2] Whatever prefix we choose to assert that cross-compiled clients,
built using the 32bit-flavor mingw64 toolchain, should be
configured. I think the mingw64 guys recommend using anything
EXCEPT /mingw -- because they don't want to conflict with stuff
from mingw.org (or, more accurately, they don't want to run the
risk that stuff from mingw.org would conflict with THEM)
[3] Whatever prefix we choose to assert that cross-compiled clients,
built using the 64bit-flavor mingw64 toolchains, should be
configured. I'm partial to --prefix=/mingw64.
Naturally, cygport's cross{-client?}.cygclass would arrange that the
actual install prefix would be
${D}/usr/$target-triple/sys-root/$configured-prefix
before packing up whatever's underneath ${D}.
Now, IF the supposition above (about JonY really wanting to provide
multilib) is correct, then we can figure out how the -m32 mode of a
*later* release of the mingw64-64bit compiler would work. But...walk
first, then run.
And maybe JonY doesn't even care much about multilib.
>> 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
Yep.
> 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.
True.
> 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.
Right. The only problem for run-in-place would be if the application
exe had the [dosified?] target path hardcoded in (e.g. neither /mingw or
C:\MinGW would match /usr/$target/sys-root/mingw -- nor
C:\cygwin\usr\$target\sys-root\mingw)
But...that's a relocatibility issue; apps properly ported to win32
should avoid these (using gnulib progreloc support?) anyway, since users
like to install native apps in C:\Program Files\foo or C:\Util\foo or
who KNOWS where...
But...THAT, at least, is not *our* concern.
> I'm going to proceed along these lines. /me rebuilds everything again
> for umpteenth time.
Sigh. Me too.
>> 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.
Yes, you are correct. Originally, I wrote "/usr/sys-root/$prefix" and
Corinna appeared to like that -- but it won't actually work that way if
you want to use gcc's "sys-root" support. For THAT to work, the
"sys-root" must be under gcc's own $prefix/$target/. IIUC.
> 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.
Well, I have to say, I often wonder WHY gcc even bothers to ship .la's
for their runtime libs. I mean, you get them "for free" because gcc
uses libtool to build them (except for libgcc), but...they really just
appear to cause problems, and least in my experience with mingw.org's
gcc-4.x releases.
It's not like you need the .la's to figure out the dependencies of the
runtime libs; gcc (or the other language drivers) do that automatically
anyway. And if you're using libtool to link, libtool already analyzes
the link command to determine the $postdeps and $predeps for each
language -- so the "extra" information in the .la just confuses the
matter. Finally, is one even ALLOWED to try to dlopen a language
runtime? What possible reason would there be to worry about that?
So...I typically *delete* the .la files corresponding to the language
runtime libraries, on mingw.org. And I've yet to encounter any problems
with doing that; OTOH, leaving them in place, often DOES cause problems
-- especially when you try to explicitly use --{static|shared}-libgcc or
--{static|shared}-$langruntime.
Instead of "fixing" the gcc .la's, could we simply delete them?
> That would be the natural result of using a sysroot, pending the issues
> above.
Yay for me.
>> cross-toolchain.cygclass
>> cross.cygchain
>
> 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.
That's what I was hoping. Separation of concern = simpler code = easier
to understand and maintain.
> Why do you think mingw*-binutils/gcc need to be handled
> differently than other toolchains?
(*) NOTE: I'm assuming that we would continue to use
--enable-version-specific-runtime-libs.
Only because, for other (e.g. ELF) toolchains, the "sysroot" stuff CAN'T
run on the same Host as the compiler. And even if they did (e.g. if we
were talking about an IRIX n64 ABI $host cross compiler for IRIX o64 ABI
$target), you'd use LD_LIBRARY_FLAGS or ld.so.conf to set up the runtime
loader -- so you'd never relocate the compiler's runtime .so's from
/usr/lib/gcc/$target/VER/ to /usr/$target/sys-root/$prefix/lib -- where
the "cross-compiled" client .so's all live.
But for cygwin+mingw, the sysroot stuff CAN run on the compiler's $host,
AND you probably DO want to relocate the compiler's runtime .dll's from
/usr/lib/gcc/$target/VER to /usr/$target/sys-root/$prefix/bin, where the
cross-compiled client .dll's all live.
That difference means a (slightly) different .cygclass for mingw $target
toolchains, than for other $targets. Or a little custom logic in the
same cross-toolchain.cygclass.
>> 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 agree, now that I've thought about it more.
>> 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.
Ah, but *I* know where it is, so I can at LEAST do
info /usr/$target/share/info/gcc.info
with any other plan, I can't locally check the documentation for my
currently installed cross-compiler.
> http://lmgtfy.com/?q=gcc+manual&l=1 :-D
Did I say, locally? <g>
>> 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
This is one case where I think the overly-strict reliance on the FHS
definition of 'shared' is a case of cutting off your nose to spite your
face: "The /usr/share hierarchy is for ***all*** read-only architecture
independent data files."
Well, "all" of them except the ones that don't logically belong there,
or can't go in /usr for some other reason...
Unfortunately, your last objection is more telling:
> Besides which, binutils and gcc don't have our latest (patched?) gettext
> macros,
The only relevant patch in "our" gettext's m4 macros is this:
src/gettext-0.17/autoconf-lib-link/m4/lib-link.m4
@@ -415,7 +415,9 @@
case "$found_dir" in
*/$acl_libdirstem | */$acl_libdirstem/)
basedir=`echo "X$found_dir" | sed -e 's,^X,,' -e
"s,/$acl_libdirstem/"'*$,,'`
- LIB[]NAME[]_PREFIX="$basedir"
+ if test "$name" = '$1'; then
+ LIB[]NAME[]_PREFIX="$basedir"
+ fi
additional_includedir="$basedir/include"
;;
esac
I'm not sure if this patch is directly related to the behavior you
describe, but it could be:
> so they result in LIBINTL=/usr/lib/libintl.a, and their build
> systems leave no way to override that static linkage.
I see. Yes, we'd really want the (cross) gcc and binutils apps to link
against their own internal libintl.a, since the internal one would have
our custom --datarootdir definition, so that it would look in the
"correct" place for the proper version of the i18n stuff.
> Doing the
> autoreconf dance with these is no simple matter either.
No, it isn't. DaveK has already mentioned that his gcc cygport takes
great care to manually run autoconf and automake only in specific
directories where needed, and he does not run autoreconf. (I think the
big issue with that is the libtool macros; e.g. our patched versions).
> So while I
> agree it's suboptimal, unfortunately for now I think we may need to go
> that way as well.
Yes, given the static /usr/lib/libintl.a problem, I think you're right.
Sigh.
I guess I need to go research my old notes about that lib-link patch,
and see about getting it upstream. Then, once gcc-4.9 switches to
gettext-0.20...
>> 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.
Ack.
--
Chuck
