porting

早期freebsd实现

Portability of the new file(1) command.
@(#) $Id: PORTING,v 1.11 1993/09/23 21:47:23 christos Exp $

Read this file only if the program doesn't compile on your system.

This release has been around UNIX; it has been compiled and tested
in the following environments:

SunOS sqarc 4.1.1 8 sun4
	No problems.
ULTRIX squint 4.2 0 RISC
	No problems.
A/UX sqmac 3.0a9 SVR22 mc68020
	No problems.
AIX sqibm 2 3 000XXXXXX100
	Had weird "make" problems making "magic" file automatically; just
	built it by hand. Your mileage may vary.
SCO sqwang 3.2 2 i386
	Compiles fine; their weird make can't handle "[a-z]*" as a dependancy,
	so build magic by hand. Runs fine.
sqzme sqzme 3.1.1 3 3B2
	The 3B2 SVR3 needed a few tweaks as well as COPTS = -Ilocalinc
	in order to compile.

This version, reluctanly, includes <stdlib.h>, which won't exist
on older systems or those that aren't even close to the ANSI C
standard. There is a null "stdlib.h", and some other bogus headers,
in subdirectory "localinc"; if you get complaints about missing
stdlib.h and others, uncomment the line with COPTS=-Ilocalinc
in the Makefile, and try again.

You must have either <stdarg.h> or the older <varargs.h>, otherwise you'll
have to butcher some routines in print.c.

Beyond that, I have tried to make a program that doesn't need any
command-line defines (-D) to specify what version of UNIX is in use,
by using the definitions available in the system #include
files. For example, the lstat(2) call is normally found in
4BSD systems, but might be grafted into some other variant
of UNIX. If it's done right (ie., using the same definitions),
my program will compile and work correctly. Look at the #ifdefs
to see how it's done. 

I've also tried to include source for all the non-portable library routines
I used (getopt, str*).   Non-portable here means `not in every
reasonably standard UNIX out there: V7, System V, 4BSD'.
These are in subdirectory "localsrc", and not used unless you
need them; again, see the Makefile.

There is one area that just might cause problems. On System
V, they moved the definition of major() and minor() out of
<sys/types.h> into <sys/sysmacros.h>.  Hence, if major isn't
defined after including types.h, I automatically include sys/sysmacros.h.
This will work for 99% of the systems out there. ONLY if you
have a system in which  neither types.h nor sysmacros.h defines
`major' will this automatic include fail (I hope). On such
systems, you will get a compilation error in trying to compile
a warning message. Please do the following: 

	1) change the appropriate #include at the start of fsmagic.c
and	2) let me know the name of the system, the release number,
	   and the name of the header file that *does* include
	   this "standard" definition.

If you are running the old Ritchie PDP-11 C compiler or
some other compiler that doesn't know about `void', you will have
to include `-Dvoid=int' in the variable COPTS in the Makefile.

Other than this, there should be no portability problems,
but one never knows these days. Please let me know of any
other problems you find porting to a UNIX system. I don't much
care about non-UNIX systems but will collect widely-used magic 
numbers for them as well as for UNIX systems.

Mark Moraes and Christos Zoulas
(address in README)