This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


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

Re: GCC cross- compiling: 'no rule to make target'


Marcin Wolcendorf wrote:
> 
> Anyway- I would like to learn, how to build cross- compilers (I'm afraid ;-) I'll need it in near
> future), thus I'd like to know how to build i586-cygwin32-to-i386-aout under Linux, which I can't.
> Script  I use stops with following error message:
> "
> In file included from include/syslimits.h:7,
>         from include/limits.h:11,
>         from ../../src/gcc/libgcc2.c:1105:
> /home/myhomedir/b-i586-cygwin32/gcc/include/limits.h:117: No include path in which to find limits.h
> make[1]: *** [libgcc2.a] Error 1
> "

 The inclusion route is shown backwards: libgcc2.c includes the GCC's own <limits.h>, which includes
the GCC's <syslimits.h> (both in the 'gcc/include'), which then tries to include the target system's
own <limits.h>, but it doesn't exist in this case...

> Why there wasn't any errors building aout, and building cygwin32 there are?

 This problem comes with the systems which don't have <limits.h>, those which have <limits.h> don't
have
the problem.

 But in gcc-2.95.2 the GCC's own <limits.h> doesn't now include the <syslimits.h> and so not the
target system's own <limits.h>, which then causes problems with some targets like Solaris7, when
something in the target's <limits.h> isn't defined ('PATH_MAX not defined'...)

 Anyway the 'limits.h' chain should be that the target system's own <limits.h> should be included in
the beginning of the GCC's <limits.h> ('#include_next <limits.h>'). The <syslimits.h> is just a stub
header which does the inclusion, so including <syslimits.h> in <limits.h> is the normal practice.

 All this is just too complicated, so I normally just copy the target's own <limits.h> as
<syslimits.h>
into the 'include' subdir in the GCC-build directory, if there is a <limits.h> with the target
headers.
If there isn't, I delete the line '#include_next <limits.h>' in the original <syslimits.h>-stub...

 Somewhere there should be a note like "Be prepared to edit the <limits.h> include chain...".

 To learn build cross-compilers is perhaps almost just the same as to learn build something else --
To
learn how to solve these kind of problems... Unfortunately the problems may exist and the solutions
to them may be quite personal. Copying the target's own <limits.h> as <syslimits.h> for GCC, if it
exits,
or removing the line with the '#include_next <limits.h>' from the original <syslimits.h>, is my
solution.
And adding the '#include <syslimits.h>' to the beginning of <limits.h> if some things are needed
from
the target's limits.h, if there aren't the inclusion yet (now dropped from gcc-2.95.2).
 
> I just wasn't able to build Linux-to-i586-cygwin32, I was able to build Linux-to-i386-aout. But, as I
> used a script for whole process and as first step of building Linux-to-i586-cygwin32 failed, I wrote
> that whole build failed. And this step failed for reasons written above.

 Mumit Khan should have step-by-step instructions for Linux-to-Cygwin and Linux-to-Mingw32
cross-tools.
Going through the 'http://sourceware.cygnus.com/cygwin' should give the Mumit's homesite address...
I build these now and then, but don't remember any special problems. That problem with <limits.h>
may
have been existed, but it is one of those 'known problems'...

> >  Perhaps it wasn't the Linux-to-i386-aout, but your
> >  Linux-to-i586-cygwin
> 
>         That's right!
> 
> > compiler which failed... Or your Makefile had a wrong compiler to
> > produce something....
> 
>         I don't know.
> 
> >  The rules:
> >
> >   *_FOR_TARGET            - tools for the i386-aout
> >   *_FOR_BUILD             - tools for Linux
> >   plain names             - tools for Cygwin
> >   HOST_CC                 - the same as CC_FOR_BUILD !!!!!!!
> >   OLDCC                   - the same as CC_FOR_TARGET !!!!!!
> >
> >  Besides the last two, the toolnames in Makefile are easy to check,
> >  the HOST_CC is really misleading...
> 
>  Well, I'm going to check this. I wanted to use some ready to use tools (i.e. scripts to automate the
> process), and didn't intend to dig through all make matters, but it looks like i will have to :-|

 I configure now always using a script, derived from a script for some earlier case or for the
earlier
GCC version, where some important values for those '*_FOR_BUILD', '*_FOR_TARGET' etc. are defined in
the environment before going to configure. But I remember from the past that those like HOST_CC and
OLDCC weren't right in the Makefile. So I may have edited the 'gcc/Makefile.in' to have :

  OLDCC = $(GCC_FOR_TARGET)
and
  HOST_CC == $(GCC_FOR_BUILD)

instead of the original :

  OLDCC = cc
and
  HOST_CC = $(CC) -b $(host)

or something which was wrong...

 Building cross-compilers is generally harder than building native compilers. The config files for
most targets are narrow-mindedly for only the native case and the needed target libs are aimed for
the native case. The symlinks between the shared libs are generally wrong for the cross-compiler
case,
the 'libc.so' may be a script which tries to link with '/lib/libc.so.6' and '/usr/libc_nonshared.a'
(the '*-linux-gnu' targets) etc. So for each specific cross-compiler there should be specific
instructions, the Linux, SVR4 and SVR4-like (FreeBSD-elf) targets with their shared libs could have
some generic instructions, or one must have some understanding about what the compiler parts are
and what it needs while compiling and linking...

 It is quite probable that someone has built a specific cross-compiler earlier, so asking about a
specific problem may help. Generally providing the error message with the command etc. from which
it resulted, and sending it to this list can help to solve the problem. You did this with the
<limits.h> case and that was just the right thing to do...

 BTW, what is the GCC version you are going to build for a Linux-to-Cygwin compiler?  I have both
the egcs-1.1.2 and gcc-2.95.2 and the previous makes smaller binaries, so I have continued to use
it as my production compiler, even after building the latter. In both cases the Mumit's patches
for the 'plain vanilla' egcs-1.1.2/gcc-2.95.2 sources are needed to fix some things for the Win32
host/target (for the Win32-hosted tools to be built).

 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]