ckuins.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

  2. Compile ckwart.c "by hand":  cc -o wart ckwart.c, or:

  3. Try various other tricks.  E.g. one Linux user reported that that adding
     the "static" switch to the rule for building wart fixed everything:

     wart: ckwart.$(EXT)
           $(CC) -static -o wart ckwart.$(EXT) $(LIBS)

If your compiler supports a compile-time option to treat ALL chars (and
char *'s, etc) as unsigned, by all means use it -- and send me email to let
me know what it is.

To add compilation options (which are explained later in this document) to
your makefile entry without editing the makefile, include "KFLAGS=..." on the
make command line, for example:

  make linux KFLAGS=-DNODEBUG
  make bsd "KFLAGS=-DKANJI -DNODEBUG -DNOTLOG -DDYNAMIC -UTCPSOCKET"

Multiple options must be separated by spaces.  Quotes are necessary if the
KFLAGS= clause includes spaces.  The KFLAGS are added to the end of the CFLAGS
that are defined in the selected makefile entry.  For example, the "bsd" entry
includes -DBSD4 -DTCPSOCKET, so the second example above compiles Kermit with
the following options:

  -DBSD4 -DTCPSOCKET -DKANJI -DNODEBUG -DNOTLOG -DDYNAMIC -UTCPSOCKET

(Notice how "-UTCPSOCKET" is used to negate the effect of the "-DTCPSOCKET"
option that is included in the makefile entry.)

WARNING: Be careful with KFLAGS.  If you build C-Kermit, change some files,
and then run make again using the same make entry but specifying different
KFLAGS than last time, make won't detect it and you could easily wind up with
inconsistent object modules, e.g. some of them built with a certain option,
others not.  When in doubt, "make clean" first to make sure all your object
files are consistent.  Similarly, if you change CFLAGS, LIBS, or any other
items in the makefile, or you rebuild using a different makefile entry, "make
clean" first.

If you create a new makefile entry, use static linking if possible.  Even
though this makes your C-Kermit binary bigger, the resulting binary will be
more portable.  Dynamically linked binaries tend to run only on the exact
configuration and version where they were built; on others, invocation tends
to fail with a message like:

  Can't find shared library "libc.so.2.1"

4.2. The C-Kermit Initialization File

There are several choices for how to handle the C-Kermit initialization file.

 a. The default action is to execute ~/.kermrc (i.e. the ".kermrc" file in
    the user's login directory) upon startup.  But since the initialization
    is standardized, it would be wasteful on multiuser systems to duplicate it
    in every user's home directory.

 b. Define a system-wide initialization file (described below).

 c. Install the standard initialization file in the system-wide PATH as an
    executable Kerbang script (ckermit2.txt Section 7.19).  Users who want to
    take advantage of the services directory and other features that are
    defined in the standard initialization file can "run" the initialization
    file to get them, whereas those who don't need them can run Kermit
    directly.

If you want to define a system-wide initialization file for C-Kermit, rather
than making each user have her/his own copy, define the symbol CK_SYSINI to be
the full pathname of the file, e.g.:

  -DCK_SYSINI=\\\"/usr/local/lib/kermit/ckermit.ini\\\"

It's best to edit the makefile to add this, because there is no good method
for putting it on the 'make' command line with KFLAGS -- the number of escapes
(\\\\...) for the doublequotes would depend on how deeply the particular make
entry is nested; each level of nesting strips off another layer of escapes.
Here's one example that works, but other targets will be different:

  make sunos41 "KFLAGS=-DCK_SYSINI=\\\\\\\"/usr/local/lib/ckermit.ini\\\\\\\""

Or, you can define CK_DSYSINI (note "D") to build C-Kermit with its built-in
default name for a system-wide init file, /usr/local/bin/ckermit.ini, or
/usr/share/lib/kermit/ckermit.ini, depending on which version of UNIX it is.
Since no quoting is needed, this one works with KFLAGS, e.g.:

  make sunos41c KFLAGS=-DCK_DSYSINI

The question arises: if you want C-Kermit to have a system-wide initialization
file, should it take precedence over the user's own?  There are valid reasons
for answering yes or no.  By default, if you build C-Kermit with a system-wide
initialization file, it will take precedence over the user's -- that is, it
will be executed instead of the user's, if the user has one.  You might also
want to set things up so the user's init file is executed if she has one, but
if she doesn't, the system-wide one will be.  Either setup is possible.
Assuming CK_SYSINI is defined, then the following symbols determine the order:

  CK_INI_A
    This means the system-wide init file is looked for first; if found, it
    is executed.  If not found, the user's init file is executed.

  CK_INI_B
    This means the user's init file is looked for first; if found, it is
    executed.  If not found, the system-wide init file is executed.

If CK_SYSINI is defined, but neither CK_INI_A nor CK_INI_B are defined (or
both of them are), then CK_INI_A is assumed.

If you build Kermit with CK_SYSINI and CK_INI_A, you can "chain" to the user's
own initialization file (if any) by ending (or starting, depending on the
desired precedence) the system-wide init file with a command like:

  if exist \v(home).kermrc take \v(home).kermrc

In any case, the initialization file should chain to the user's customization
file, as in this clause from the standard ckermit.ini:

  if exist \m(_myinit)  {		; If it exists,
      echo Executing \m(_myinit)...	; print message,
      take \m(_myinit)			; and TAKE the file.
  }

4.3. The 2.x BSD Makefile

Use the separate makefile ckubs2.mak.  Read the instructions in that file.
NOTE: C-Kermit 6.0 was probably the last version of C-Kermit that could be
built for 2.x BSD -- it just barely fit with a few bytes to spare into the
maximum overlay model.  More recent versions are larger.  But it might be
possible to make it fit using different overlay arrangements; anybody who
cares is welcome to try.

4.4. The Plan 9 Makefile

Use the separate makefile ckpker.mk.

4.5. Makefile Failures

First, be sure the source files are stored on your current disk and directory
with the right names (in lowercase).  Second, make sure that the makefile
itself does not contain any lines with leading spaces: indented lines must all
start with horizontal TAB, and no spaces.

Then make sure that your UNIX PATH is defined to find the appropriate compiler
for your makefile entry.  For example, on SunOS systems, "make sunos41" builds
C-Kermit for the BSD environment, and assumes that /usr/ucb/cc will be used
for compilation and linking.  If your PATH has /usr/5bin ahead of /usr/ucb,
you can have problems at compile or link time (a commonly reported symptom is
the inability to find "ftime" during linking).  Fix such problems by
redefining your UNIX PATH, or by specifying the appropriate "cc" in CC=
and CC2= statements in your makefile entry.

During edits 166-167, considerable effort went into making C-Kermit compilable
by ANSI C compilers.  This includes prototyping all of C-Kermit's functions,
and including the ANSI-defined system header files for system and library
functions, as defined in K & R, second edition: <string.h>, <stdlib.h>,
<unistd.h> (except in NeXTSTEP this is <libc.h>), and <sys/stdtypes.h>.  If
you get warnings about any of these header files not being found, or about
argument mismatches involving pid_t, uid_t, or gid_t, look in ckcdeb.h and
make amendments.  C-Kermit assumes it is being compiled by an ANSI-compliant C
compiler if __STDC__ is defined, normally defined by the compiler itself.  You
can force ANSI compilation without defining __STDC__ (which some compilers
won't let you define) by including -DCK_ANSIC on the cc command line.

On the other hand, if your compiler defines __STDC__ but still complains about
the syntax of Kermit's function prototypes, you can disable the ANSI-style
function prototyping by including -DNOANSI on the command line.

For SCO OpenServer, UNIX, ODT, and XENIX compilations, be sure to pick the
most appropriate makefile entry, and be sure you have installed an SCO
development system that is keyed to your exact SCO operating system release,
down to the minor version (like 2.3.1).

Also note that SCO distributes some of its libraries in encrypted form, and
they must be decrypted before C-Kermit can be linked with them.  If not, you
might see a message like:

  ld: file /usr/lib/libsocket.a is of unknown type: magic number = 6365

To decrypt, you must supply a key (password) that came with your license.
Call SCO for further info.

If your compiler uses something other than int for the pid (process id) data
type, put -DPID_T=pid_t or whatever in your CFLAGS.

If you get complaints about unknown data types uid_t and gid_t, put
-DUID_T=xxx -DGID_T=yyy in your CFLAGS, where xxx and yyy are the appropriate
types.

If your compilation fails because of conflicting or duplicate declarations for
sys_errlist, add -DNDSYSERRLIST to CFLAGS.

If your compilation dies because getpwnam() is being redeclared (or because
of "conflicting types for getwpnam"), add -DNDGPWNAM to your CFLAGS.
If that doesn't work, then add -DDCGPWNAM to your CFLAGS (see ckufio.c around
line 440).

If the compiler complains about the declaration of getpwnam() during an ANSI C
compilation, remove the declaration from ckufio.c or change the argument in
the prototype from (char *) to (const char *).

If you get complaints that getpwuid() is being called with an improper type,
put -DPWID_T=xx in your CFLAGS.

If you get compile-time warnings that t_brkc or t_eofc (tchars structure
members, used in BSD-based versions) are undefined, or structure-member-
related warnings that might be traced to this fact, add -DNOBRKC to CFLAGS.

If you get a linker message to the effect that _setreuid or _setregid is not
defined, add -DNOSETREU to CFLAGS, or add -DCKTYP_H=<blah> to CFLAGS to make
C-Kermit read the right <types.h>-kind-of-file to pick up these definitions.

If you get a message that _popen is undefined, add -DNOPOPEN to CFLAGS.

If you get a complaint at compile time about an illegal pointer-integer
combination in ckufio.c involving popen(), or at link time that _popen is an
undefined symbol, add the declaration "FILE *popen();" to the function zxcmd()
in ckufio.c (this declaration is supposed to be in <stdio.h>).  If making this
change does not help, then apparently your UNIX does not have the popen()
function, so you should add -DNOPOPEN to your make entry, in which case
certain functions involving "file" i/o to the standard input and output of
subprocesses will not be available.

If your linker complains that _getcwd is undefined, you can add a getcwd()
function to ckufio.c, or add it to your libc.a library using ar:

#include <stdio.h>

char *
getcwd(buf,size) char *buf; int size; {
#ifndef NOPOPEN
#ifdef DCLPOPEN
    FILE *popen();
#endif
    FILE *pfp;

    if (!buf) return(NULL);
    if (!(pfp = popen("pwd","r"))) return(NULL);
    fgets(buf,size-2,pfp);
    pclose(pfp);
    buf[strlen(buf)-1] = '\0';
    return((char *)buf);
#else
    buf[0] = '\0';
    return(NULL);
#endif /* NOPOPEN */
}

#ifdef NOPOPEN
FILE *popen(s,t) char *s,*t; {
    return(NULL);
}
#endif /* NOPOPEN */

If you get complaints about NPROC having an invalid value, add a valid
definition for it (depends on your system), as in the cray entry.

If you get some symbol that's multiply defined, it probably means that a
variable name used by Kermit is also used in one of your system libraries that
Kermit is linked with.  For example, under PC/IX some library has a variable
or function called "data", and the variable "data" is also used extensively by
Kermit.  Rather than edit the Kermit source files, just put a -D in the make
entry CFLAGS to change the Kermit symbol at compile time.  In this example, it
might be -Ddata=datax.

Some symbol is defined in your system's header files, but it produces
conflicts with, or undesired results from, Kermit.  Try undefining the symbol
in the makefile entry's CFLAGS, for example -UFIONREAD.

Some well-known symbol is missing from your system header files.  Try defining
in the makefile entry's CFLAGS, for example -DFREAD=1.

You get many warnings about pointer mismatches.  This probably means that
Kermit is assuming an int type for signal() when it should be void, or
vice-versa.  Try adding -DSIG_I (for integer signal()) or -DSIG_V (for void)
to CFLAGS.  Or just include KFLAGS=-DSIG_V (or whatever) in your "make"
command, for example:

  make bsd KFLAGS=-DSIG_V

You get many messages about variables that are declared and/or set but never
used.  It is difficult to avoid these because of all the conditional
compilation in the program.  Ignore these messages.

Some of C-Kermit's modules are so large, or contain so many character string
constants, or are so offensive in some other way, that some C compilers give
up and refuse to compile them.  This is usually because the -O (optimize)
option is included in the make entry.  If this happens to you, you can