Re: Using the new cross compilation system - and a request for help

[Harold L Hunt <huntharo at msu dot edu>]

Alexander Gottwald <Alexander.Gottwald@informatik.tu-chemnitz.de> said:

> On Tue, 9 Jul 2002, Harold L Hunt wrote:
> > 1) We are building gen_matypes.c and we are supposed to create an executable
> > that will be used during the compilation process to build a header file called
> > ``matypes.h''.  However, this executable is being built with ``cc'' (it isn't
> > clear if this is the link to /cygwin/bin/cc or if it is the host cc) but we
> > are calling it ``gen_matypes.exe'', which is clearly wrong because we want an
> > executable to use while cross compiling, not an installable executable.
> 
> diff -U3 -r1.22 Imakefile
> --- lib/GL/mesa/src/X86/Imakefile   2002/03/01 21:21:48 1.22
> +++ lib/GL/mesa/src/X86/Imakefile   2002/07/11 15:24:06
> @@ -85,11 +85,11 @@
>  MATYPES = ./gen_matypes
> 
>  matypes.h: gen_matypes.c
> -   RemoveFiles($@ ProgramTargetName(gen_matypes))
> -   -HostLinkRule(ProgramTargetName(gen_matypes),$(CFLAGS)
$(LOCAL_LDFLAGS),gen_matypes.c,$(LDLIBS))
> +   RemoveFiles($@ HostProgramTargetName(gen_matypes))
> +   -HostLinkRule(HostProgramTargetName(gen_matypes),$(CFLAGS)
$(LOCAL_LDFLAGS),gen_matypes.c,$(LDLIBS))
>     RunProgram(MATYPES,> matypes_h)
>     $(MV) matypes_h $@
> -   RemoveFiles(ProgramTargetName(gen_matypes))
> +   RemoveFiles(HostProgramTargetName(gen_matypes))
> 
>  includes:: matypes.h
> 

I have already made such a patch to my local tree.  It works fine.  I thought
I made a post a day or two ago with a patch for cross compiling?  I thought it
had just such a patch in it?  Am I losing my mind?

> > 2) Building gen_matypes.c fails because it cannot find glheader.h, mypes.h,
> > and tnl/t_context.h, which are stored over in xc/extras/Mesa/src, but it
> > appears that they should be copied during the build process to
> > build/std/exports/include.  For some reason, they are not being copied there.
> 
> no problem for me. Maybe they are not created because gen_matypes failes
> before

Nope.  gen_matypes needs those headers before it is build, since gen_matypes.c
includes those headers.  What is happening here is that the HostLinkRule
(which you created, I believe) over in xc/config/cf/cross.rules does nothing
with the flags parameter.  I recall that we couldn't pass the flags parameter
because it was defining some things that ought not to be defined when cross
compiling.  However, I have modified my HostLinkRule to pass the flags on just
as LinkRule does and I have built the whole tree without problems.  I think
only one other executable uses HostLinkRule, so as long as these two things
build we are in the clear.  Have you modified your locak HostLinkRule, or is
cross.rules not being processed on your system?  Oh yeah, the flags, in this
case, contain -I../../../../exports/include (or something close to that, I
don't feel like looking it up for an exact quote), which points the compiler
to glheader.h, mtypes.h, and tnl/t_context.h.

> 
> > There is a new problem that needs a better answer than the one that I've got
> > right now.  In xc/config/imake/imakedep.h there is a define that turns an
> > empty define for i686 into i686 == 1.  For some reason, i686 is now defined
> > during a cross compilation build and it causes our executable names, such as
> > ``i686-pc-cygwin-gcc'' and our include directories (``i686-pc.. you get the
> > point...) to become ``1-pc-cygwin-gcc''.  I had to add a ``#undef i686'' to
> > the new host.def that is used when cross compiling.
> 
> you don't need the i686-pc-cygwin32-gcc program names anymore. For me, a
> call to cross-gcc is /usr/i686-pc-cygwin32/bin/`echo gcc|sed "s%.*/%%"`
> 

How do I make it through life without accidentally killing myself?  I must
have tried 20 ways of defining the cross compiler names, or not defining them,
etc., and I never got a build to work until I started setting them to
i686-pc-cygwin-gcc and so forth.  Then you mention that they don't need to
have i686-pc-cygwin in them anymore, I try it, and voila, like magic it works.
 What gives?  Can't I get a break anymore?

Oh yeah, and you are correct.  We don't need the i686-pc-cygwin prefix anymore.

> I'll see if the imake patch compiles and will send a patch later.
> 

What imake patch?

I have had problems with imake not compiling because imake.c is looking for
glibc_major and glibc_minor, which are supposed to be defined in imakemdep.h,
but for whatever reason the #if's are wrong and imakemdep.h doesn't define
them but imake.c still ends up expecting them.  Please figure this one out for
me, it is really bugging me.  For now I've just changed imake.c and
substituted 0's for glibc_major and glibc_minor.

Harold

> bye
>     ago
> -- 
>  Alexander.Gottwald@informatik.tu-chemnitz.de
>  http://www.gotti.org           ICQ: 126018723
> 
>