This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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, 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):
> ...
> 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]