Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]
On Sun, 2010-07-11 at 14:43 -0400, Charles Wilson wrote:
> 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;
Since you keep mentioning mingw.org, AFAICS they still ship gcc-3.4.4,
which we (sort of) have already. Is that what you are referring to, or
do you simply mean the latest binutils and gcc built for target
i686-pc-mingw32? If the latter, are any patches or specific configure
options necessary (besides using dw2 exceptions instead of sjlj)?
> [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.
Are you sure about this? The /mingw prefix is hard-coded into all
gcc/config/i386/t-mingw*.
> 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}.
Ack.
> 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.
>From the POV of building other packages, trying to build any package
simultaneously for a multilib setup is a lot of work, and cygport is
certainly not up to that right now. I think it should suffice if we
provide both i686 and x86_64 mingw64 compilers.
> (*) NOTE: I'm assuming that we would continue to use
> --enable-version-specific-runtime-libs.
Of course.
> 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.
You might, but others likely will not.
To make it even more confusing, the man1 pages are $target-namespaced,
so they are safe in /usr/share/man/man1, but the man7 pages are not.
The latter have very little to do with the actual packages, however, so
I'm not concerned about removing those.
> The only relevant patch in "our" gettext's m4 macros is this:
I was referring to shrext in config.rpath:
http://www.cygwin.com/ml/cygwin/2008-04/msg00659.html
Although now that I think about it, we could just manually patch that
for each toolchain package.
> 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.
Huh? Customizing the location of locales doesn't require a different
libintl, you just need to make sure that the second argument to
bindtextdomain(3) is set correctly. So if we want to "invent"
$prefix/$target/share for toolchain.cygclass packages, cygport just
needs to set --datarootdir accordingly.
But even with --datarootdir=/usr/$target/share, somehow the locales
*still* end up in /usr/share/locale. Whether it's worth trying to rely
on the native binutils/gcc locales for at least partial translations
(--enable-nls then remove ${D}/usr/share/locale) or not (--disable-nls),
I suppose is debatable.
Now back to work on this...
Yaakov
Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]
On 11 July 2010 19:43, Charles Wilson wrote: > 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. Sounds good. May JonY's maintainership be long and prosperous, but maintainers do come and go, so if even NightStrike isn't convinced of the need for multilib, it's better to avoid the extra complexity to make things easier for any future maintainers. Andy
Re: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]
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 --pref
RFU: nasm-2.08.02-1
Upstream release, please upload. wget -x -nH --cut-dirs=2 \ http://scarff.id.au/file/cygwin/nasm/nasm-2.08.02-1-src.tar.bz2 \ http://scarff.id.au/file/cygwin/nasm/nasm-2.08.02-1.tar.bz2 Thanks. -- Dean http://scarff.id.au/ -- software bugs and workarounds
RFU: cppcheck-1.44-1
Please upload: --- wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.44-1.tar.bz2 \ http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.44-1-src.tar.bz2 --- Keep cppcheck-1.43-1 as previous and all others can be removed. Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
