Chapter 1 CIN Overview

Solaris 1.x

LabVIEW for the Sun can use external code compiled in a.out format and prepared for LabVIEW using a LabVIEW utility. The unbundled Sun C compiler is the only compiler that has been tested thoroughly with LabVIEW. Other compilers that can generate code in a.out format might also work with LabVIEW, but this has not been verified. The C compiler that comes with the Sun does not use extended-precision floating-point numbers; code using this numeric type will not compile. However, the unbundled C compiler does use them.

Solaris 2.x

The preceding information for Solaris 1.x is true for Solaris 2.x, with one exception—LabVIEW 3.1 and higher for Solaris 2.x uses code compiled in a shared library format, rather than the a.out format previously specified.

Note: LabVIEW 3.0 for Solaris 2.x supported external code compiled in ELF format.

Existing Solaris 1.x and Solaris 2.x (for LabVIEW 3.0) CINs will not operate correctly if they reference functions that are not in the System V Interface Definition (SVID) for libc, libsys, and libnsl.

Recompiling your existing CINs using the shared library format should ensure that your CINs function as expected.

HP-UX

As previously stated, the HP-UX C/ANSI C compiler is the only compiler that has been tested with LabVIEW.

Unbundled Sun ANSI C Compiler and

HP-UX C/ANSI C Compiler

With these compilers, you create a makefile using the shell script lvmkmf (LabVIEW Make Makefile), which creates a makefile for a given CIN. You then use the standard make command to make the CIN code. In addition to compiling the CIN, the makefile puts the code in a form that LabVIEW can use.

The format for the lvmkmf command follows, with optional parameters listed in brackets.

lvmkmf [-o Makefile] [-t CIN] [-ext Gluefile] LVSBName

Chapter 1 CIN Overview

LVSBName, the name of the CIN or external subroutine that you want to build, is required. If LVSBName is foo, the compiler assumes the source is foo.c, and the compiler names the output file foo.lsb.

-o is optional and supplies the name of the makefile that lvmkmf creates. If you do not use this option, the makefile name defaults to

Makefile.

-t is optional and indicates the type of external code you want to create. For CINs, you should use CIN, which is the default.

-ext is needed only if this external code calls external subroutines. The argument to this directive is the name of a file that contains the names of all subroutines that this code calls, with one name per line. The file is not necessary to run the lvmkmf script, but it must be present before you can successfully make the CIN. If you do not specify a -ext option, lvmkmf assumes that the CIN does not reference any external subroutines.

In Solaris 1.x, the makefile produced assumes that the directories for the files cin.o, cinetc.o, makeglueBSD.awk, and lvsbutil are in certain locations. If these assumptions are incorrect, you can edit the makefile to correct the pathnames.

In Solaris 2.x, the makefile produced assumes that the directories for the files cin.o, cinetc.o, makeglueSVR4.awk, and lvsbutil are in certain locations. If these assumptions are incorrect, you can edit the makefile to correct the pathnames.

In HP-UX, the makefile produced assumes that the directories for the files cin.o, cinetc.o, makeglueHP.awk, and lvsbutil are in certain locations. If these assumptions are incorrect, you can edit the makefile to correct the pathnames.

If you specify the -ext argument to the lvmkmf script, the makefile creates temporary files. For example, if the gluefile name is bar, the makefile creates files bar.s and bar.o. Neither the CIN nor the makefile needs these files after the CIN has been created.

If you make external subroutines, you need to create a separate makefile for them. The lvmkmf script creates a file called Makefile unless you use the -o option. For this reason, you may want to place the code for each subroutine in separate directories to avoid writing over one Makefile with the other. If you want to place the code in