FAQs and documentation

09 Jun 2001: Updated, with a simpler build procedure.

Please note: I don't have HOWTOs. I have UWOT?s.

UWOT? Problems compiling Gcc under Cygwin?

If you've been having seemingly never ending trouble getting the compiler to build under cygwin, here's a procedure I've developed that seems pretty solid. This procedure is for building the normal ppc compiler from the diffs I've provided and the gcc-2.95.3 and binutils-2.10 releases; to build the altivec version, just substitute vx-vec- for vx-ppc- in the names of the diff files.


  Ok.  Here's a recipe that should work.  We're going to start by making
a subdirectory in the home directory to do the build in:

$ cd ~
$ mkdir new-gcc
$ cd new-gcc

  Now you've got to copy the .tar.gz files from whereever they live

$ cp /some/dir/or/other/gcc-2.95.3.tar.gz .
$ cp /some/dir/or/other/binutils-2.10.tar.gz .
$ cp /some/dir/or/other/vx-ppc-binutils.diff.tar.gz .
$ cp /some/dir/or/other/vx-ppc-gcc.diff.tar.gz .

  and unpack them:

$ tar zxvf gcc-2.95.3.tar.gz
$ tar zxvf binutils-2.10.tar.gz
$ tar zxvf vx-ppc-binutils.diff.tar.gz
$ tar zxvf vx-ppc-gcc.diff.tar.gz

  then we can get rid of them, since they're only copies (don't do this
if you put your only copies into new-gcc!)

$ rm gcc-2.95.3.tar.gz binutils-2.10.tar.gz \
       vx-ppc-binutils.diff.tar.gz vx-ppc-gcc.diff.tar.gz

  Next, you need to apply the patches.

$ patch -p 1 -d binutils-2.10 <vx-ppc-binutils.diff
$ patch -p 1 -d gcc-2.95.3 <vx-ppc-gcc.diff

  Now we make some build directories

$ mkdir build-gcc
$ mkdir build-binutils

  Now, in order to deal with the CRLF problem, we provide mountpoints
to access the source code in text mode; this converts CRLF <-> LF.

$ mkdir /gcc-src
$ mkdir /binutils-src
$ mount -u -t `cygpath -aw \`pwd\`/gcc-2.95.3` /gcc-src/
$ mount -u -t `cygpath -aw \`pwd\`/binutils-2.10` /binutils-src/

  This uses pwd to print the current directory, then calls cygpath on the
concatenation of the pwd output with the names of the subdirectories in
our new-gcc dir in order to convert them to windows-style for the mount
command.

  Next, a necessary precaution.  This next step might be superfluous by
now but it can't do any harm:

$ mkdir /usr/local/lib/gcc-lib/powerpc-wrs-vxworks
$ mkdir /usr/local/lib/gcc-lib/powerpc-wrs-vxworks/2.95.4

[ The reason for this is because the build process seems to generate a lot
of relative paths starting at this directory, which is where most of the
compiler will be installed once it is built, so it's best to make sure the
directory really is there!  AFAIUI this caused problems in 2.95.2, and
should be fine in 2.95.3+, so this step may be obsolete, but it can't hurt. ]

  One final problem: the gcc archive comes with a copy of the texinfo
utility that is used to generate the .info files for the manual, but it
won't work with cygwin.  Fortunately cygwin offers the same functionality
itself, so we just need to rename, delete or move the texinfo subdir in
the gcc sources.

$ mv gcc-2.95.3/texinfo gcc-2.95.3/old.texinfo

  Right: preparations out of the way, time to get started.  The first 
thing we do is configure, build and install the cross binutils:

$ cd build-binutils
$ /binutils-src/configure --target=powerpc-wrs-vxworks -v 2>&1 | tee conf.log
$ make all install 2>&1 | tee build.log
$ cd ..

  Now we've got the cross binutils installed, we must put them in the PATH
setting so that the cross compiler can find them when it wants to build
libraries for the target:

$ export PATH=/usr/local/bin:$PATH

  It's quite possible you will already have this directory in your path,
in which case you can omit this step.

  Now we configure and build gcc itself.  Note that for this stage, you
must have Tornado installed on the PC.  In fact, all you really need is the
header files from the Tornado\target\h directory.  In the example that
follows, I assume that the full tornado dir. tree is installed on the PC,
and that the environment variable WIND_BASE points to it.  If not, you
can just replace all the backtick/cygpath monkey business with the path
to the headers directly.

$ cd build-gcc
$ /gcc-src/configure --target=powerpc-wrs-vxworks --with-included-gettext  \
--with-gnu-as --with-gnu-ld --with-headers=`cygpath -aup                   \
${WIND_BASE}`/target/h --with-included-gettext --enable-languages=c,c++ -v \
2>&1 | tee conf.log
$ make LANGUAGES="c c++" all install 2>&1 | tee build.log

  And there you should have it, although I know of one or two problems 
that might crop up: it might fail when it starts building the modules
of libgcc, if the fixincs process has (as it sometimes does) gotten the
wrong kind of lineends into the fixed headers.  If this occurs, your
build will end with some error message along the lines of 'Invalid token in
expression', the way to fix it is to say

$ cd gcc/include
$ find . -type f -ls -exec dos2unix \{\} \;
$ cd ../..

which needs you to have a dos2unix converter in your /bin directory; if
you don't have one, just drop this into a file /bin/dos2unix

#!/bin/sh
cp $1 $1.dos && tr -d '\015' <$1.dos >$1 && rm $1.dos

and make it runnable by executing

$ chmod ugo+x /bin/dos2unix

  After converting the line ends, you just repeat the make command and
it will carry on from where it left off.

  Last of all, test your compiler out on a simple 'hello world' program:

$ cat >hw.c << EOT

#include <stdio.h>

int hello_world (void)
{
  printf ("Hello VxWorld!\n");
  return 0;
};

EOT

$ powerpc-wrs-vxworks-gcc hw.c -o hw

  Download that to your target and it should run fine

UWOT? Installing the new Gcc compiler.

Once you've done this, the compiler is installed in the standard location under /usr/local/bin, /usr/local/lib/gcc-lib/powerpc-wrs-vxworks, and /usr/local/powerpc-wrs-vxworks. Rob Targosz of altsoftware taught me that by renaming these files to match the names in the Tornado directory tree and putting them in place of the existing files, it would work in the Tornado framework, and his technique is the basis for my binary distributions.

To be precise:

- the entire /usr/bin/powerpc-wrs-vxworks directory, which contains bin, lib, include and sys-include directories, replaces WIND_BASE/host/WIND_HOST_TYPE/powerpc-wrs-vxworks;
- the powerpc-wrs-vxworks/2.95.4 directory under /usr/local/lib/gcc-lib/ is copied into the corresponding place under WIND_BASE/host/WIND_HOST_TYPE/lib/gcc-lib;
- all the executables powerpc-wrs-vxworks-*.exe from the /usr/local/bin directory EXCEPT FOR powerpc-wrs-vxworks-size.exe are renamed to *ppc.exe and placed in WIND_BASE/host/WIND_HOST_TYPE/bin;
- a copy of the cygwin dll is also placed there, as the executables need it to run.

There are also some header files that need a bit of fixing: because the WRS default makefiles use the -nostdinc flag, the compiler's fixed versions which live in the gcc-lib/powerpc-wrs-vxworks/2.95.4 directory can't override the WRS include files. The changes that need to be made are:

- replace the WRS include file stdarg.h, varargs.h, va-ppc.h, arch/ppc/toolPpc.h, arch/ppc/archPpc.h with the fixed versions from the gcc-lib/powerpc-wrs-vxworks/2.95.4/include subdirectory.
- do something about the fact that struct ip_opts in netinet/in.h has a member with the same name - ip_opts - as the struct itself, which the compiler doesn't allow. I replace it with a renamed version.

This is basically how my binary installs work; the install scripts place all the files in the directory tree where they can easily be found later, but with different extensions; then the selcompiler script moves copies of the files and directories with the appropriate extensions into the places of the original WRS files.

UWOT? Problems compiling Gcc under other hosts?

The source code should be fine for other systems, such as Linux and Solaris as well. You can follow the procedure outlined above, but with just a couple of changes:

- You can skip the stage of mounting directories in textmode. Just replace the references to "/gcc-src/configure" with "../gcc-2.95.3/configure" and to "/binutils-src/configure" with "../binutils-2.10/configure"
- You should omit the step of renaming the texinfo subdirectory, and omit the --with-included-gettext flag from the gcc configure command.
- You won't have to worry about all that dos2unix grief!
- Installation is similar to cygwin. The Tornado host/<host type> directory structure mirrors the /usr/local directory structure, with a <target type> subdirectory and files in bin/ and lib/gcc-lib/<target type>.

There are other potential problems that may arise while building the compiler:

UWOT? "You need to install autogen!"

Oops. No you don't. It just means that I've got my timestamps mixed up. You need to cd into the gcc top level source directory, and run

contrib/egcs_update --touch

This file should really be called gcc_update these days, but there you go.

CORRECTION: Oops, you might need it after all! Simon Watts writes to say

Your FAQs state that you dont need autogen. This may be true if
compiling GCC from your source, but if, like me, you apply the diffs to
the original gcc source, then you certainly do! Whats worse, the build
process doesnt baulk but just continues with the original fixinc*
scripts when it cannot find autogen. There is a report in the make
output, but that isnt obvious. This lead to the xgcc being built
without the fixed headers for varargs. It may be useful to make that
clear in the FAQs? The business of fixinc is cryptic enough already!
(as in lack of docs).

Should you find that you do, it can be got from http://autogen.freeservers.com/. Alternatively, a simpler solution would be if I provided you with a set of diffs to patch the original inclhack.sh file in the source code so that you don't have to generate it from the inclhack.def template. And here they are :-D

UWOT? stddef.h: Invalid token in expression

means you have to change the EOLs in all the files in $objdir/gcc/gcc/include from dos to unix style. Quick answer:

cd <$objdir>/gcc/gcc/include find . -type f | -ls -exec dos2unix \{\} \;

If you don't have a dos2unix command already, just drop this into a file /bin/dos2unix

#!/bin/sh cp $1 $1.dos && tr -d '\015' <$1.dos >$1 && rm $1.dos

and make it runnable by executing

chmod ugo+x /bin/dos2unix

UWOT? ($srcdir)/gcc/cpp.texi: No such file or directory
make: *** [cpp.info] Error 2

UPDATED: This one shouldn't happen any more if you follow the new build guidelines.

texinfo files need a different build procedure under cygwin. The simplest solution once this error has occurred is to just create dummies:

touch cpp.info touch gcc.info

and make do without them. The *proper* solution is to rename or delete the texinfo subdirectory in the gcc source code before beginning to build, and add the flag --with-included-gettext to your configure command.

UWOT? fdmatch.c: In function `fdmatch':
fdmatch.c:59: storage size of `sbuf1' isn't known
fdmatch.c:60: storage size of `sbuf2' isn't known
make[1]: *** [fdmatch.o] Error 1
make[1]: Leaving directory `/usr/local/src/gcc-2.95.3/powerpc-wrs-vxworks/libiberty'
make: *** [all-target-libiberty] Error 2

UPDATED: This one shouldn't happen any more. I've made a change to gcc/libio/gen-params that fixes it.

Well, believe it or not, this isn't really an error, it means your build has completed!

The thing is, when you 'make all' in the top level directory, that includes quite a few additional targets as well as the gcc cross compiler itself.

Among these, it compiles some for the host machine, like libiberty which is linked into the compiler for support functions, makeinfo which is used to process the .info files, but it also builds libs for the target machine: libstdc++, libgcc, libio which provides stdio functions if your C runtime library doesn't and for some reason it wants to build libiberty for the target as well. But, libiberty doesn't compile on VxWorks and it fails.

Anyway, you don't need any of those except libgcc, because the rest of the functionality is built into VxWorks! If you've enabled the C++ language support in the kernel, you've got your libstdc++; and of course the rest of VxWorks provides the remaining C runtime library, stdio and malloc and is* and so on.

So the final stage at this point, is to cd into the gcc subdirectory, and type

make LANGUAGES="c c++" install

Shazam! You now have a fully working VxWorks compiler under Cygwin. You can compile files under Cygwin using either

powerpc-wrs-vxworks-gcc

gcc -b powerpc-wrs-vxworks

and the resulting executables will be ready to download to a VxWorks target. The compiler should generate properly relinkable files for the VxWorks target dynamic linker by using the -r flag.

UWOT? "Can't find cpp0.exe" or "Can't find as.exe":

UPDATED: This one shouldn't happen any more. In fact it shouldn't have happened at all :-( my bad.

This one is my fault, sorry. This bug exists only in the first version of my code and is now fixed. It can be worked around by adding the directories
%WIND_BASE%\host\x86-win32\powerpc-wrs-vxworks\bin
and %WIND_BASE%\host\x86-win32\lib\gcc-lib\2.95.3
to the beginning of your PATH environment variable in My Computer / properties / environment variables.

UWOT? libgcc.a and libstdc++.a:

UPDATED: This one shouldn't happen any more; thanks to a whole bunch of patches, libstdc++ will now build correctly for gcc. See the Info page for more about using libgcc and libstdc++.

Since libstdc++.a won't build for 2.95.3, you might find it handy to try

cd %WIND_BASE%\host\x86-win32\lib\gcc-lib\powerpc-wrs-vxworks\2.95.3\ copy libgcc.a libstdc++.a

if you find a compilation failing when it tries to link.

You should hopefully be able to add -lgcc to your compiles to get full support for long long integers. However there is a problem: the default WRS makefile environment includes the -nostdlib flag, which cancels out the -lgcc flag.

To fix this you must remove -nostdlib from the VxWorks BSP macro LD_PARTIAL. While you're doing that you could add -lgcc to the LD_PARTIAL_FLAGS.