This is the mail archive of the
mailing list for the Cygwin project.
Re: cygport cross-compiling beta1
On Tue, 2010-07-20 at 00:53 -0400, Charles Wilson wrote:
> Paolo Bonzini mentioned that he had a different patch, and promised to
> rebase to latest and repost. He didn't. I pinged him.
Hopefully that comes soon, because without that, I don't see any choice
but to add $CROSS_SYSROOT to $prefix. FWIW Fedora seems to do the same,
and now I see why. :-(
> I'll release a new cygwin libtool with whatever comes of that
> discussion, as soon as it gets even close to a resolution.
While you're at it, will this include support for -flto (without -Wc,)?
With gcc 4.5 on the way (for several platforms) this will be important.
Also, I mentioned -fstack-protector* on bug-libtool:
But as I noted in the next message in that thread, that doesn't help
with tag=CXX. I'm not sure how to solve that short of not interfering
with g++ and trusting it to link libstdc++ and libgcc without libtool's
help (what a concept!).
> Don't care. Fedora should be used as a guide, not a cage.
Not only does it provide precedence, but now that we understand fully
*why* they package the way they do, it should be easier to accept it.
> 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?
Certainly not in the sysroot (only libraries need to be there), and
possibly not even built by cygport. For example, if you're
cross-compiling a program to be used by others on Fedora, you would
probably use rpm to build it, no?
> 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.
And if it was prefix=/usr/local you would still need root privileges to
install (at least I sure hope so), and then you get the joys of
adjusting PATH and LD_LIBRARY_PATH for /usr/local. (Just went through
that dealing with Solaris.) The only case where you avoid this is with
a $HOME prefix, which is naturally going to be good for only personal
> 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.
> 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):
> I can send the logs, if you like.
Well, AFAICS *that* is wrong, nor is that how it is in my test package.
I'll have to try rebuilding it again.
> 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.
Distros maintain patches for still-in-use older software to fix
compatibility with new GCCs. Otherwise, yes, they'll actually have to
fix their code. But let's face it, most distros don't support gcc-3.4
anymore, certainly not as a primary compiler, so why must we,
particularly given our limited resources?