Compiling a C program on Subsystem for Unix-based Applications (SUA) & Interix
by Rodney Ruddock
This paper provides an introduction to what is available and what
needs to be installed to compile C programs with Subsystem for Unix-based Applications (SUA) and Interix. Some example are provided for novice programmers
or programmers unaccustomed to command line compiling.
For building C programs on SUA and Interix there are several choices of
compiler. Available are gcc, Visual C, Intel and PGI.
The gcc suite of tools is available as part of the installation
of the Utilities and SD for SUA/Interix. This is labeled as the "GNU SDK"
when you choose the Custom Install (always recommended). The suite includes
the GNU debugger gdb. The gcc suite is capable of building
binary objects, binary executables and shared libraries.
Microsoft's Visual C can be used from the SUA/Interix system to produce
SUA/Interix binaries (often called POSIX binaries). You can use any of
the Visual C versions available as part of Visual Studio. You may also
install the Visual C only package that is available for free from
Microsoft. To correctly utilize Visual C two utilities are provided
with SUA/Interix: cc and c89. If you are versed in the
Unix-world these names will be familiar. With SUA/Interix cc and
c89 provide different levels of command line option strictness.
While c89 adheres strictly to the C89 standard for options and
their placement, cc is more relaxed with option positions on
the command line. This means cc is the most flexible when build
scripts are migrating or porting to SUA/Interix.
Both the Intel and PGI C compilers require that the SDK's from the Utilities
and SDK installation be installed. The SDK's provide the include files,
manual pages for API's and other supporting utilities. Both are capable of
producing and linking with SUA/Interix binaries.
For more information about each of these offerings please visit their respective web sites.
Installing Needed Components
For a full description of what should be installed please refer to
the other white papers and videos:
Note that you should install both of the SDK's: the SUA/Interix SDK
and the GNU SDK. This will get you cc, c89, the gcc
suite including the gdb debugger, API manual pages and shared
library support (runtime).
After you have installed both SDK's then you can install the other
compilers (MSVC, Intel, PGI) if you have them.
Use the Command Line
Users of a GUI for compiling and linking programs should familiarize
themselves with the shell to issue the command line actions. This is good
background and knowledge for you to have and clears away much of the
mystism of GUI's.
Customizing Editors and Shells
From Microsoft the utilities include a couple of the basic editors (vi and ed).
Some people prefer some other editors. If you have not already done so, I
suggest that you install additional software packages from the SUA Community
Tools Warehouse individually or via
one of the Bundles. This is also true for the shells. The basic installation
comes with ksh/sh and csh/tcsh (version 6.14).
From the Tools Warehouse you can update tcsh to a more recent version as
well as add bash and/or zsh.
Start any one of the shells. In the examples below I will be using sh.
You can start some of the shells from the Start Menu.
Now edit a file named "hello.c" and enter the code below.
This program should shock no one. It gives us a familiar file to work
with for compiling and linking. After saving this file run the following
commands in your shell:
$ vi hello.c
$ gcc -o hello hello.c
If you have MSVC, PGI or Intel installed you can substitute "gcc" above
with "cc", "c89", "pcc", etc.
Using Build Tools
Available with SUA / Interix are the familiar build tools that most sites
use when building programs. This includes make, gmake,
xmkmf and jam. The version of make is BSD based and
has all of BSD's familiar (and very useful) extensions. gmake is
GNU's version of "make" which has different extensions than BSD make.
Linking with Libraries
Of course SUA / Interix comes with several libraries located in "/usr/lib"
and in "/usr/X11/lib". The largest and most familiar is libc
of course. On the 32-bit systems the libraries are available as both
static and shared libraries. On 64-bit systems the libraries are available
(in 64-bit) as static libraries only. You can build and link 32-bit
programs on the 64-bit machines if you want or need to in which case both
static and shared libraries are available.
Different systems have over time blended some libraries into libc.
This is simply due to more memory being available and it making developers
lives a little easier. On SUA/Interix the pthreads API's are all
within libc while the RPC library librpclib is still
separate. You can discover or find API's that remain unlinked at the end of
a build with a command line (or small script or alias) using a
combination of nm and grep. For example to find the API
"zaphod_head_right" in the libraries in the "/usr/lib" directory:
$ for i in `ls /usr/lib/lib*.a`
> echo $i
> nm $i | grep zaphod_head_right
Once found you can them add the link. As an example:
$ gcc -o hello2 hello2.c -lrpclib
Default Linking Actions
With the cc and c89 commands the resulting binaries are
always static binaries. That is, the binaries do not used shared libraries.
With gcc the resulting binaries use shared libraries (if
available) by default. You can change this behavior by adding the
gcc option "-static" at the link phase. When a resulting binary
that uses shared libraries is run the shared libraries are loaded at
runtime the same as on other systems; with ld.so. The ld.so
that ships from Microsoft is only aware that it should search for
the shared libraries in the directories "/usr/lib" and "/usr/X11/lib"
plus the directories listed in the environment variable LD_LIBRARY_PATH.
An enhanced verison of ls.do is available from the Tools Warehouse
as part of the libdl software package. The enhanced ld.so
also checks "/usr/local/lib" (the site of may shared libraries)
and "/usr/local/ssl/lib" in addition
to those listed previously. Also the enhance version can use the
ldconfig utilities (also part of the libdl package) so
you can set more default paths that all programs, run by all users will
search. This can ease a lot of problems particularly when daemons
are being started or the environment variable LD_LIBRARY_PATH may not
or cannot be set.
Building C programs on SUA/Interix is virtually the same as on other Unix
and Linux systems. While there are some variation you will encounter, these
are no different than when moving between other systems.