This is the mail archive of the crossgcc@sources.redhat.com 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] |
"Oldno7 (Guillermo Hernandez)" wrote: > Hi there!. I've being following this list for a days (trying to see if > my trouble comes out and working to resolve it with similar threads) > but I'm at the end of my knowledges (-few if anyone asks-). The maillist archives should have helped, your problem really is quite common... > I'm trying to make a cross compiler targeted to a i586-pc-cygwin32. > The sources from I'm trying to generate the cross compiler are: > binutils-2.11, gcc-2.95.3, > newlib-1.9.0 and gdb-5.0 For the Cygwin target you need to get the Cygwin-runtime, ie the headers and libraries for it, the 'real stuff', not anything else, so the newlib-1.9.0 is wrong.... ftp://sources.redhat.com/pub/cygwin/snapshots How to collect from the 'latest', I don't remember, but the Cygwin- pages should tell this... Also building the Cygwin-libs from the sources is possible, but is it really necessary? As always, the sources are for those who work with the Cygwin-host and its problems, not for any 'normal' Cygwin-target developer. You either work to better the Cygwin-layer or develop apps for the Cygwin host and leave this job for others... The alternative Mingw packages the 'runtime' headers and libs nicely, so probably the Cygwin too... >_fixunsdfsi > In file included from include/limits.h:117, > from include/syslimits.h:7, > from include/limits.h:11, > from ../../gcc-2.95.3/gcc/libgcc2.c:1105: > /usr/home/query/cross/gcc/gcc/include/limits.h:117: limits.h: No such > file or directory > *** Error code 1 The Cygwin headers come with the 'limits.h' and the idea is that the GCC's own 'limits.h' includes this via the 'syslimits.h'. And the #include- chain should end there... Most probably your problem comes from the GIGO-effect but tracking the limits.h' chain is always the best approach if the problem continues after installing the 'right stuff' (the Cygwin-target stuff). I have met this problem sometimes and sometimes the problem is that the target system's own 'limits.h' was never used ("PATH_MAX undefined" or something telling it...) Cheers, Kai ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |