On Tue, 2010-07-20 at 00:53 -0400, Charles Wilson wrote: > http://www.mail-archive.com/libtool-patches-mXXj517/[email protected]/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.
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: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7330/focus=7341 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 use. > 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. Not AFAIK. > 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/lib/lib32/libiberty.a > ... > > 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? Yaakov
