The only systems I'm sure everything builds on are my own - and even
that can fail in cases such as a very old program that hasn't been
recompiled in years.

That said, most of this stuff should build fairly readily.  Some things
which are common across enough of the software to be worth mentioning
as common issues:

- Many of the Makefiles end with ".include <local-prog>".  This is a
   reference to a file from what you can find in PACKAGES under
   "makefiles".  If you don't want to set up a full-fledged /local
   analog, you can probably compile and link by hand without too much
   trouble, using the Makefile variables as a guide to what flags to
   use, what files to compile, etc.

- I do not quite write in C.  I write in the language accepted by gcc,
   as hacked on by me.  This is fairly close to the language accepted
   by stock gcc; the major difference is that I've added labeled
   control structure.  This can be identified by syntax errors when
   using a stock compiler that prove to be due to strings <"like this">
   in the source.  I've written a filter to run between the
   preprocessor and the compiler to deal with most cases of it; see the
   lcs-cvt entry in PACKAGES for more.  For those interested in exactly
   what I've done to gcc, see my NetBSD git repos (see below).

- There are various interdependencies (as a simple example, ideacrypt
   depends on libidea).  While I've tried to note these, I every now
   and then notice one I missed, so there are probably others I've
   missed.

- NetBSD has a tendency to allow one include file (<foo.h>, say) to
   depend on another (<bar.h>, say) being included, but without making
   <foo.h> include <bar.h> itself.

   While this is not entirely a bad thing, in that I believe that if
   userland code uses anything from <bar.h>, it should include <bar.h>,
   even if it uses it just so as to use <foo.h>'s stuff, I also believe
   that (a) the order of the inclusion should not matter, that
   including <foo.h> and <bar.h> should be equivalent to including
   <bar.h> and <foo.h>, and (b) userland code should not need to
   include <bar.h> if it does not use the <foo.h> facilities that need
   <bar.h>.  For example, the 1.4T <sys/stat.h> uses u_int32_t in its
   definition of the (user-visible) struct stat.  If user code does not
   itself use u_int32_t, nor anything else from <sys/types.h>, it
   should not need to include <sys/types.h>, even if it includes
   <sys/stat.h> - which it may do for other reasons, such as to define
   S_ISUID and related symbols.

   This is relevant here because when I find include files which depend
   on others but don't include them, I consider it a bug, and "fix" it
   by including the missing include file.  Such a fix is not the best
   fix, since it then leads to code that depends on include files but
   doesn't include them - the right fix would be to, for example, have
   <sys/stat.h> include, say, <sys/types___u_int32_t.h> and then use
   __u_int32_t, with <sys/types.h> including <sys/types___u_int32_t.h>
   and defining u_int32_t as __u_int32_t.  This way, code that uses
   u_int32_t won't "work" if it happens to bring in <sys/stat.h> but
   not <sys/types.h>, but, also, bringing in <sys/stat.h> won't produce
   errors if <sys/types.h> hasn't been included earlier.

   I don't do that; it would be more work than the cleanness of the
   result seems worth to me, especially since nobody but me would
   probably ever get any benefit from it.  But the fix I do do means
   that my code is incompatible with the stock - buggy, in my
   estimation - include files.  I have no simple recommendation for
   this, except to fix the include files.  You can probably deal with
   it by adding the necessary include files (in some cases this may
   need nothing more than reordering #includes).

If you have trouble I haven't mentioned, please feel free to tell me
about it.  If nothing else, I can add a note here for future users.

Many of my things are kept using git for revision control.  In
particular, I've done a lot of things to the NetBSD versions I use, and
those changes are kept in git repos.  See /mouse/git-repos in the FTP
area.  In particular, if you want to know exactly what I've done to gcc
for a given NetBSD version, the thing to do is git clone the relevant
repo and look at history for the affected directories.  If you have
trouble dealing with git for some reason, write me and we'll see what
we can work out.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B