6. Miscellaneous Topics

All of the extra compiler checks described in section 5.1.3 refer
to a single C source file, however tcc also has support
for a number of intermodular checks. These checks are enabled by means
of the -im command-line option. This causes the producer to
create for each C source file, in addition to its TDF capsule output
file, a second output file, called a C spec file, containing a description
of the C objects declared in that file. This C spec file is kept associated
with the target independent TDF as it is transformed to a target dependent
capsule, an assembly source file, and a binary object file. When these
binary object files are linked then the associated C spec files are
also linked using the C spec linker, spec_linker, into
a single C spec file. This file is named a.k by default.
It is this linking process which constitutes the intermodular checking
(in fact spec_linker may also be invoked at the TDF merging
level when the -M option is used).

When intermodular checks are specified, tcc will also
recognise input files with a .k suffix as C spec files
and pass them to the C spec linker.

The nature of the association between a C spec file and its binary
object file needs discussion. While these files are internal to a
single call of tcc it can keep track of the association,
however if the compilation is halted before linking it needs to preserve
this association. For example in:

> tcc -im -c a.c

the binary object file a.o and the C spec file a.k
need to be kept together. This is done by forming them into a single
archive file named a.o. When a.o is subsequently
linked, tcc recognises that it is an archive and splits
it into its two components, one of which it passes to the system linker,
and one to the C spec linker.

Intermodular checking is described in more detail in [3]. In tchk
intermodular checking is on by default, but may be switched off using
-im0.

In section 4.3 we discussed how tcc environments
can be used to specify APIs. There is one API environment however
which is so exceptional that it needs to be treated separately. This
is the system environment, which specifies that tcc
should emulate cc on the machine on which it is being
run. The system environment specifies that tcc
should use the system headers directory, /usr/include,
as its default include file directory, and should define all the machine
dependent macros which are built into cc. It will also
specify the 32-bit portability table on 32-bit machines.

Despite the differences from the normal API environments, the system
environment is indeed specifying an API, namely the system
headers and libraries on the host machine. This means that the .j
files produced when using this environment are only "target independent"
in the sense that they can be ported successfully to machines which
have the exactly the same system headers and predefined macros.

Using the system headers is fraught with difficulties. In particular,
they tend to be very cc-specific. It is often necessary
to use the -not_ansi and -nepc options together with
-Ysystem merely to negotiate the system headers. Even then,
tcc may still reject some constructs. Of course, the
number of problems encountered will vary considerably between different
machines.

To conclude, the system environment is at best only suitable
for experimental compilation. There are also potential problems involved
with its use. It should therefore be used with care.