This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: cygport cross-compiling beta1
On 7/19/2010 9:49 PM, Yaakov (Cygwin/X) wrote:
> On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
>> I'll address issues with libtool/pkgconfig at that
>> time, as well (short version: our version of pkgconfig claims to support
>> sysroot via $PKG_CONFIG_SYSROOT_DIR, but newer versions have supposedly
>> improved that support. Also, there was one patch, and another promised,
>> on libtool-patches addressing just this issue, in the last week).
>
> Where is that discussion? Fixing libtool is imperative to using the
> sysroot the way I'm proposing; otherwise we'll be forced to actually
> prepend $sysroot to $prefix.
http://www.mail-archive.com/libtool-patches@gnu.org/msg05488.html
Paolo Bonzini mentioned that he had a different patch, and promised to
rebase to latest and repost. He didn't. I pinged him.
I'll release a new cygwin libtool with whatever comes of that
discussion, as soon as it gets even close to a resolution.
>> 1. As discussed previously, I disagree that all the mingw* toolchains
>
> The opinions I heard on #mingw-w64 was that /mingw was a necessary evil.
> IWO they don't "like" it, but it's hard to avoid.
OK.
> FWIW the Fedora mingw64 packages also use $sysroot/mingw.
Don't care. Fedora should be used as a guide, not a cage.
>> 2. Furthermore, I think it is pretty likely that, for a linux $target,
>
> That depends on why you're cross-compiling. The primary point of making
> cross-compiled packages for a distro is not to use them on their host
> but to use them for cross-compiling other software in the build's
> sysroot, so you want those prefixes to match (think RPATH). While you
> could build that other software which you are going to use on the host
> with cygport, that's a secondary benefit IMO (much like canadian-cross).
But at SOME point, SOME part of what you've built on $host is supposed
to be used, eventually, by somebody, on $target, right?
Where should THAT live?
If I'm on linux and have a devel environment, I can always compile with
--prefix=/home/me/my-builds even if I don't have root. But...with this
cross.cygchain, I can't do that from my cross-host; I'm trapped in the
thou-shalt-have-root prison and to USE anything I build, I *must* build
with --prefix=/usr -- and then I can't use it on the $target without
root privilege.
rpm-build doesn't restrict you that way; sure, it *defaults* to /usr,
but you CAN override (yes, there are issues on the 'rpm --install' side
wrt. root, but there are also workarounds for that). I'm not sure about
ebuild, but I *think* you can override it, too.
Why shouldn't cygport allow that?
VVV======================= cut ======================VVV
(3)-(5) are all dead horse issues; we've beaten them to death. I'll
respond, but we don't really need to discuss these any further. Most of
them are the domain of the maintainer of the specific toolchain, and if
he/she disagrees with you OR me, they can easily include the appropriate
commands in their cygport(5).
>> 3. Toolchain Documentation (currently deleted during src_install): I
>> think the documentation specific to each cross compiler that
>> conflicts with the native compiler -- e.g. info files, man{2-7}
>> pages not renamed by 'make install' -- should go under
>> /usr/$target/share
>
> Fedora's MinGW packaging policy says clearly that duplicate
> documentation should not be included.
Again, don't care. Guide, not cage.
And, once again, you are assuming as true the very thing I am saying
will be false; when you proceed from different premises naturally the
conclusions will differ.
The documentation will not be "duplicate documentation" because the
documentation for different versions of gcc is different. In the
(unlikely!) event that the versions for i686-w64-mingw32 gcc and
mips-sun5-solaris10 gcc are the same, then -- by accident -- you might
have two copies of the same documentation.
> Inventing /usr/$target/share for
> the sole purpose of info and man pages which won't be found by info or
> man anyway doesn't make any sense to me.
Then package an /etc/profile.d script that appends or prepends to
MANPATH and INFOPATH.
Or assume some modicum of intelligence on the part of people with the
gumption to actually install a *cross compiler*, and allow them to
manually set INFOPATH/MANPATH as appropriate when they are using a given
cross tool.
Or the provider of the cross toolchain can patch the .texi files -- as I
did, for all of the automake* and autoconf* packages -- to install
versions under different names.
SOMETHING.
Just assuming that "the docu for the native compiler will be good enough
for whatever bleeding edge or ancient cross compiler(s) are installed"
seems not entirely realistic, to me.
But again, this is the purview of the cygport(5), anyway.
>> 4. NLS. I think the cross toolchains should be compiled with
>> --disable-nls,
> With NLS you will still have at least partial translations, which is
> better than nothing, no?
Wherever the lookup (english) string hasn't changed, the correct
translation will be found. Wherever it HAS changed, then...you get the
english version.
I suppose that is no worse than all-english-all-the-time, in the case of
--disable-nls. The more divergent the two versions of gcc, the more
english and the less i18n you get.
What I was worried about was *incorrect* translations, but it doesn't
appear that will happen.
>> 5. Packaging: I think that the languages for the compilers should be
>> split into separate packages, and that the language runtime DLLs
>> should have individual packages. Ditto with respect to other
>> packages which provide DLLs, like pthreads etc.
>
> No, no, and NO.
Yes, yes, yes, YES.
That's four. I win.
^^^================== cut ==================^^^
>> - mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib/libgcc_s.a
>> ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/${PV[1]}.*/
>> + mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib64/libgcc_s.a
>> ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/${PV[1]}.*/
>
> Fixed.
>
>> Also, this packaging oddity:
>> mingw64-x86_64: usr/x86_64-w64-mingw32/lib64/libiberty.a
>
> x86_64-w64-mingw32 is potentially a multilib arch, hence the lib64. If
> the gcc were actually built multilib, you'd see a lib32 and lib64.
>
>> mingw64-i686: usr/i686-w64-mingw32/lib/lib32/libiberty.a
>
> You mean /usr/i686-w64-mingw32/lib/libiberty.a? The only way you would
> get lib32/libiberty.a (not lib/lib32) is with multilib, which I disabled
> in my builds.
Nope, I was using your cygports, with only the changes I posted in my
previous email; thus, the mingw64-i686-gcc-4.5.20100708-1.cygport I used
was directly from your cygport-cross-examples.tar.bz2. I got (this is
my reverse-sorted list of the files in the tarball):
...
usr/i686-w64-mingw32/sys-root/mingw/bin/libgfortran-3.dll
usr/i686-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll
usr/i686-w64-mingw32/sys-root/mingw/bin/
usr/i686-w64-mingw32/sys-root/mingw/
usr/i686-w64-mingw32/sys-root/
usr/i686-w64-mingw32/lib/lib32/libiberty.a
usr/i686-w64-mingw32/lib/lib32/
usr/i686-w64-mingw32/lib/
usr/i686-w64-mingw32/
usr/bin/i686-w64-mingw32-gfortran.exe
usr/bin/i686-w64-mingw32-gcov.exe
...
I can send the logs, if you like.
>> Why the differences? Where should libiberty.a actually live, relative to
>> /usr/$target? Is it possible this library should actually get relocated
>> to the sysroot?
>
> These locations are correct; libiberty is installed in /usr/$target/lib
> $suffix, and like other toolchain components don't get installed into
> the sysroot. This directory is also in the default search path, as you
> can see with $target-gcc -print-search-dirs.
OK, the differences between the various toolchains just looked a little
suspicious.
>> However, given the dependency structure of the gcc3 packages, this means
>> you pretty much have to also remove, using setup,
>> gcc-core
>> gcc-g++
>> gcc-java
>> gcc-objc
>>
>> Note that this conflict means that the current gcc-mingw* packages (and,
>> thus, the gcc 3.x packages) conflict with the new mingw-gcc-* and
>> mingw-binutils-* packages. Also, this may have implications for the
>> upgrade process, when the "real" mingw32-gcc cross toolchain is
>> released. Even if we mark the gcc (3) packages obsolete, we probably
>> have to repackage them and their gcc-mingw* friends to fix this upgrade
>> problem, and perhaps relieve the conflict. Somehow?
>
> We can just remove the gcc-mingw* deps from gcc3*. But the bigger
> question is, do we still *need* gcc3 in the distro?
Once we can build setup.exe with gcc4, then I don't believe we *need*
it. And we can *definitely* get rid of mingw-gcc*; at that point, gcc
-mno-cygwin breaks badly, and we get to say "it's been deprecated for
over a year, and now it is no longer supported. Use this spiffy new
cross compiler".
But...somebody out there might have (cygwin) code that doesn't compile
with gcc4. They ought to fix their code, but...this is not an ideal world.
>> The following flags are used in the official mingw compiler, but not here:
>> --enable-libstdcxx-debug
>
> Reading the description, I'm not so sure we need (or want) this.
>
>> --enable-shared (but that's okay, as it is default)
>> --enable-libgomp
>
> AFAIK --enable-shared and --enable-libgomp are the defaults.
Then...why didn't I get a libgomp library? Oh, err, never mind. It's
because I missed to download and install the
mingw-pthreads-20100619-1.tar.bz2 package for bootstrapping.
And there's a good reason I missed it: there isn't one under
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW/
However, there is a mingw-pthreads*cygport in the examples package. I'll
build that, then rebuild the mingw toolchain.
>> --disable-win32-registry
>
> Yes, we definitely want this.
>
>> (also, --disable-werror, and language Ada)
>
> Just hadn't bothered with Ada, that's all.
I know, that's up to DaveK. I was just being thorough.
>> The following flags are used here, but not in the official mingw compiler:
>> --disable-multilib
>> --enable-lto
>
> AFAIK these are actually the defaults.
OK.
>> I believe --enable-fully-dynamic-strings is correct, but apparently the
>> official mingw.org 4.5.0 release does not use it.
>>
>> Because 'mingw-runtime' is an existing package, and the current version
>> is 3.18-1, this new version should be -2.
>
> Oops, missed that one. But the mingw-runtime maintainer should take
> care of that when we're up to pushing this.
Right.
>> Is it usual to build linux compilers with --enable-fully-dynamic-strings?
>
> Apparently not, thanks for catching that.
>
>> Had to install libelf0 and libelf0-devel packages, in order to build.
>
> Right, as LTO uses libelf on ELF targets.
Like I said, these were just my running notes.
>> I don't think either of these two lines belong in the cygport:
>>
>> mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib/libgcc_s.a
>> ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/${PV[1]}.*/
>> # mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib32/libgcc_s.a
>> ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/4.6.0/32/
>>
>> Because there doesn't seem to be any libgcc_s.a file anywhere in the
>> build or install trees:
>
> You are correct; copy-and-paste errors.
Figured as much.
>
>> Anyway, building binutils and gcc went mostly ok, but building glibc did
>> not.
>
> I am unable to reproduce this, even after cleaning out my sysroot.
> While I was at it, I did push an updated gcc and rebuilt glibc, in case
> you want to try again.
Hmmm...it'll have to wait until next weekend, at best. I want to
experiment with cross.cygclass and the mingw-foo cygports first.
--
Chuck