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
