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

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

A new cross compilation system was implemented for XFree86 in May of 2002. 
This new system is described here:

http://www.xfree86.org/~keithp/xconf2001/cc-imake.pdf


This new cross compilation system breaks things horribly when trying to cross
compile Cygwin/XFree86 according to the instructions in the current
Cygwin/XFree86 Contributor's Guide.  I have been working to cross compile
Cygwin/XFree86 using the new cross compilation system and I have nearly been
successful, except for some problems building Mesa.  I have not yet tried to
build fonts, as this was never explicitly supported when cross compiling
Cygwin/XFree86.  After we get general cross compilation fixed I will take a
look at buidling fonts during a cross compile.

Here are the differing steps for cross compiling Cygwin/XFree86 with the new
cross compilation system, apart from copying over the includes and libs, and
downloading and building the gcc and binutils packages:

1) Grab the new host.def file from:
http://www.msu.edu/~huntharo/xwin/host-cross-20020708.def

Place this file in xc/config/cf and rename it to host.def.

2) Make a link called ``cc'' to ``i686-pc-cygwin-gcc'' in ``/cygwin/bin'':
cd /cygwin/bin
ln -s i686-pc-cygwin cc

This link is needed to make ccimake or imake (I forget which and I don't have
time to check).

3) For whatever reason, you need to make a softlink to sysdefs.h:
cd /cygwin/i686-pc-cygwin/include
ln -s mingw/sysdefs.h sysdefs.h

4) Link your build directory using lndir as per the Contributor's Guide
instructions.

5) Do a full build with the following command, note that you do not need to
set your PATH anymore (I think):
make CROSSCOMPILEDIR="/cygwin/bin" World > World.log 2>&1


Doing such a build results in a few errors, mostly related to Mesa.  Or, if we
fix the Mesa errors first we probably fix the other errors as well.  Here is
my build log:
http://www.msu.edu/~huntharo/xwin/World-cross-20020708.log.bz2 (~128 KiB)


Search the build log for either ``error '' (with the trailing space) or search
for  ``gen_matypes.c''.  You should end up on line 8333, which is making the
``includes'' target for xc/lib/GL/mesa/src/X86.  There are a couple of
problems with this failed command:

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.

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.

3) It is not clear that this gen_matypes executable is built during a native
build (I can't check right now and I need someone to report on this, as soon
as possible).  Perhaps all of these errors are due to something in Mesa being
built that should not be built because of some inappropriate define or wrong
build flag somewhere.  This could be related to the ``i686'' problem that I'll
describe below.


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.

I need to know if ``i686'' is defined when doing a native build of XFree86 on
Cygwin (once again, I can't check now and I'd appreciate the help).  It may be
that ``i686'' is just being defined on my machine because of some change from
Mandrake 8.1 to Mandrake 8.2.  Or, it could be that the new cross compilation
system is causing ``i686'' to be defined.  Either way, I need to know why i686
is suddenly defined so that I can add a better comment to the new host.def. 
Furthermore, since the broken part of Mesa relates to assembly code, it is
entirely possible that undefining i686 is causing Mesa to build a normally
skipped portion of its source tree.


Let's make a deal: anyone out there that is cross compiling needs to answer
the various little questions that I posed above.  That's all you've got to do.
 I'll take those answers and make cross compilation work again.  I would
really appreciate it if people would take some of the burden of tracking these
things down so that I don't have to spend my time on it (just think, I could
be applying patches instead).  Thanks in advance for any help.


Hopefully we will get cross compilation going again,

Harold