porting

RAM Defragmentation tools

Well, ramdefrag *should* compile without problems on any GNU/Linux system
with a working installation of GTK+ 1.2.x, and GNU libc. It *may* also
compile on non-GNU-libc systems, but maybe some fiddling is needed.
To regenerate the 'configure' script as well as the 'Makefile.in's, you'll
need automake 1.7 and (of course) autoconf.

Well, and keep in mind that we're useing the cursed AM_MAINTAINER_MODE;
this means that you may need to use the --enable-maintainer-mode switch
when calling configure if you plan to fiddle with those automake thingies.

This file yields a list of systems with known problems and workarounds.
Feel free to send a patch to <[e-mail]> or to use our
Sourceforge.net patch tracker at
<http://sourceforge.net/tracker/?group_id=98465&atid=621116> if you find
out any improvements.
Your work will be honored, really, we mean it (at least by including your
name in the THANKS file - so tell us how you would like to appear there).

FreeBSD, NetBSD, Solaris:

 - if you have the GTK libs, you've almost won. using 'gmake' instead of
   'make' should do the rest.

OpenBSD:

 - as ramdefrag uses the GNU GPL and some OpenBSD advocates claim this is
   evil, ramdefrag is not supported under OpenBSD. It may work, but we'll
   never find out.
   Well, actually, there are some fearless heroes who tried it - and one
   of them send us a patch so that ramdefrag should compile out-of-the-box
   on OpenBSD systems. But keep in mind that you have to be very, very
   careful while compiling and using ramdefrag on OpenBSD, otherwise the
   GPL will infect your fine system, spread like a virus and take away all
   of your freedom. So be wary, here be dragons.

Palm OS:

 - you may see the beginnings of a Palm OS port in the 'palm' directory
   right in the top directory of the source tarball. Feel free to join
   the porting team and to send us patches.

Others:

 - we always appreciate reports for other systems, and we'll include them
   here if you send them.