This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi YEM, Sorry for replying so late, just saving my job due to recession. I just got one solution of this problem, kindly check if this is ok to do this way. Patches are in attachment. Windows->cygwin m/c use to give for example i686-build_unknown-pc-cygwin So now I have modified to "i686-build_unknown-cygwin" Means removed pc-, so with this changes config.sub(guess) don't have any problem and they pass it smoothly. As we have discussed earlier also pc- was giving problem as it does not come in any category. Also four parts are there in this so it obeys all rules. Please check this and include this patch if no body had given you solution for this problem. For checking my concept I build arm-unknown-eabi tool change, it worked fine. I have taken trunk of crosstoolNG of 2nd Feb 09 Other patch is just refresh of latest release of 2nd Feb 09. Regards Vivek -----Original Message----- From: crossgcc-owner@sourceware.org [mailto:crossgcc-owner@sourceware.org] On Behalf Of Yann E. MORIN Sent: Tuesday, November 18, 2008 3:54 AM To: crossgcc@sourceware.org Cc: Carl Miller Subject: Re: Crosstool NG on Cygwin(WinXP): ARM922T, GCC 4.3.2, uClibc0.9.30 Hello Carl! Hello All! On Monday 17 November 2008 23:06:21 Carl Miller wrote: > On Mon, Nov 17, 2008 at 07:34:07PM +0100, Yann E. MORIN wrote: > > Unfortunately, that breaks the *-cygwin tuples, that *are* 3-part tuples, and > > don't have a vendor part. config.sub does not recognise those tuples as valid > > *-cygwin tuples. Sad, but true. > > And I'd agree with it. In a four-tuple, the third position denotes OS > kernel, and the fourth position denotes OS environment or C library. > "pc" is clearly not an OS kernel. > > I'd argue that "i686-pc-cygwin" does indeed have a vendor already. > It's "pc". What it doesn't have is an OS kernel. Which can be uniquely > inferred from the OS environment of "cygwin". Which leaves us no choice but to have the mangling done on a per-{build,host}-OS basis, and not as a generic rule. Thank you, Carl, for this explanation! Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.------------- -------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ___ | | --==< ^_^ >==-- `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | `------------------------------^-------^------------------^------------- -------' -- For unsubscribe information see http://sourceware.org/lists.html#faq
Attachment:
ct-ng.trunk-cygwin-mpfr.patch
Description: ct-ng.trunk-cygwin-mpfr.patch
Attachment:
trunk.cygwin.crosstool-ng.sh.in.patch
Description: trunk.cygwin.crosstool-ng.sh.in.patch
-- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |