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 7/20/2010 9:55 AM, Dave Korn wrote:
On 20/07/2010 05:53, Charles Wilson wrote:

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?

On the target?

I meant, *in what directory* on the target. As cross.cygclass is currently implemented, cross-compiled stuff may only be compiled-for, and installed in, the target's /usr tree, not /usr/local or /home/me/ or what-have-you.


   Re: libiberty.a, I have no idea why we even install that.  We don't install
the headers, and it has no fixed defined API or versioning, so it's basically
useless.  I wouldn't worry too much about where it ends up!

IIRC you must have it available to link to libbfd.a and libopcodes.a, and we DO provide those and their headers (in the native toolchain). However, that's the $host version. The $target version...you're probably right.


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.

Yeah, this is tricky. I don't mind if we end up telling people they can have *either* gcc-3 *or* x-mingw-gcc4 but not both at the same time. I guess it's worth testing if gcc-3 -mno-cygwin still works with up-to-date mingw cross-binutils and libs installed in place of the /usr/i686-pc-mingw32 symlinks.

Well, I guess the replacement package for the gcc(3)-mingw stuff can just create symlinks:
/usr/lib/mingw -> /usr/i686-pc-mingw32/sys-root/mingw/lib
/usr/include/mingw -> /usr/i686-pc-mingw32/sys-root/mingw/include
(or, rather, gcc-mingw-* could simply be obsoleted -- and the replacement version having a postinstall script that does what the gcc-mingw-* preremove scripts SHOULD have done, which is to remove the /usr/i686-pc-mingw32/{bin,include/lib} symlinks, and a new repackaged version of gcc(3)-core could generate the /usr/{lib,include}/mingw symlinks itself.



However, depending on how the system includes are ordered, gcc3 -mno-cygwin will then either use the "cygwin" w32api in /usr/include/w32api, or the cross versions mixed in to /usr/i686-pc-mingw32/sys-root/mingw/include.


Ditto with the system lib dirs, with respect to the w32api libs. I'll try it and see, later tonight.

--
Chuck


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