TOC, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14

3) COMPILING C-LINDA PROGRAMS

3.1) How do I get my C-Linda program to link when I'm calling FORTRAN routines? C++ routines?

clc links programs using the shell script linda_cc_link. Linda_cc_link normally uses the C compiler to link Linda programs, but the environment variable LINDA_CC_LINK can be used to specify an alternate program for linking.

3.2) Can I ignore the warning messages like

"prog.cl:10: warning --- no matching Linda op."

This could mean that clc noticed that a tuple is being created with an out or eval, but is never accessed with an in, inp, rd, or rdp. It is common practice not to in tuples created with eval, so that is a common reason for the warning. But the message could mean that a tuple is being in'd that was never out'd. If the in is executed, it is guaranteed to deadlock. Thus, the warning should be checked. If it refers to an eval, it is harmless.

3.3) How do I get a link map with C-Linda?

On SunOS 4.1, use

lc -linda link_args "-Qoption ld -M" -o prog prog.cl

3.4) Why do I get the message:

"/usr/licensed/linda/clc: /usr/linda/true_clc: not found"

when trying to compile my C-Linda program?

It means that the distribution is not properly installed. Anytime the distribution is moved, it needs to be reinstalled. Just go into the top level distribution directory (containing install_pkg), and execute install_pkg.

If the same distribution is used on multiple machines, there could be a problem if the different machines have different paths for reaching the distribution. You may need to create some symbolic links to the distribution on some of the machines so that everyone can use the same path, and then execute install_pkg with the canonical path as an argument to install_pkg. For example, after creating a symbolic link called /usr/licensed/linda pointing to the distribution on all
machines, install linda on just one of the machines with the command:

  0nstall_pkg /usr/licensed/linda

Now, the installation should work on all the machines.

3.5) How do I make clc use a different C compiler?

The C-Linda compiler, clc, uses a collection of shell scripts in the bin directory of the Linda distribution to preprocess .cl files, compile C programs, and link executables. These shell scripts can be customized to meet your specific needs. To make this easier and avoid having to modify the distribution, many of the shell scripts use environment variables, which if defined, will change the behavior of the shell script.

The Network Linda shell scripts are:

      <linda dir>/bin/linda_cc
		        " linda_cc_link
		        " linda_cpp
		        " postcpp_cc

and the CDS Linda shell scripts are:

      <linda dir>/cds/bin/linda_cc
		        " linda_cc_link
		        " linda_cpp
		        " postcpp_cc

You could edit any or all of these shell scripts, changing "cc" to the desired C compiler, or "cpp" to a different C preprocessor.

It is possible that all you have to do is set some environment variables to the path of the new compiler:

      etenv LINDA_CC /usr/local/bin/acc
		      etenv LINDA_CC_LINK /usr/local/bin/acc
		      etenv POSTCPP_CC /usr/local/bin/acc

You could also specify an option for the compiler, as in:

      etenv LINDA_CC "/usr/local/bin/acc -ANSI"
		      etenv LINDA_CC_LINK "/usr/local/bin/acc -ANSI"
		      etenv POSTCPP_CC "/usr/local/bin/acc -ANSI"

Unfortunately, these have no effect on linda_cpp, so it would have to be modified in order to use a different preprocessor.

3.6) How do I make clc use gcc instead of cc?

See answer 3.5 for a general discussion.

It can be as simple as this:

etenv LINDA_CC gcc
etenv LINDA_CC_LINK gcc
etenv POSTCPP_CC gcc

but this won't use the GNU C preprocessor. You may want to edit linda_cpp to use it, but that may not be necessary, depending the particular gcc installation.

3.7) How do I use ANSI C mode on my HP?

See answer 3.5 for a general discussion.

The obvious solution is to do define the environment variables as
follows:

      setenv LINDA_CC "/bin/cc -Aa"
		      setenv LINDA_CC_LINK "/bin/cc -Aa"
		      setenv POSTCPP_CC "/bin/cc -Aa"

Unfortunately, there is a problem with this on the HP. As described in section six of the C-Linda Reference Manual, clc first preprocesses the .cl file using linda_cpp, converts it to a .c file, and then compiles it using postcpp_cc. There isn't a simple way to turn off the preprocessing phase of the HP ANSI C compiler, so the output from the C preprocessor becomes the input to the C preprocessor in postcpp_cc. Many C preprocessors have no problem with this, but it causes a problem with /lib/cpp.ansi on the HP. Line directives of the form:

  # 1 "real_main.cl"

		  # 1 "/usr/local/linda/cds/lib/linda.h"

are output from /lib/cpp.ansi, which results in error messages, such as:

__lt4871.c: 1: Unknown preprocessing directive.
__lt4871.c: 3: Unknown preprocessing directive.

when they are input to /lib/cpp.ansi. The HP C preprocessor requires line directives such as:

  #line 1 "real_main.cl"

		  #line 1 "/usr/local/linda/cds/lib/linda.h"

Two possible solutions are to make linda_cpp output line directives that are legal input to /lib/cpp.ansi, or to turn off the preprocessing phase of cc. The first solution could be done using a sed command like:

     sed 's/^# *\([0-9]\)/#line \1/'

to convert the offending line directives, but it is probably better to use the second solution. Modify postcpp_cc as follows:

#!/bin/sh
		shift
		case $POSTCPP_CC in
		"")
		     /bin/cc -tp,${LINDA_PATH}bin/lcpp $*
		     ;;
		*)
		     $POSTCPP_CC -tp,${LINDA_PATH}bin/lcpp $*
		     ;;
		esac

This uses the cc -t option to change the preprocessor to be a shell script that you should create in the bin directory of the Linda distribution. The shell script could be simply:

#!/bin/sh
/bin/cp $1 $2


Note that these changes do not actually force ANSI C mode, but merely allow the use of the -Aa option without problems. These changes can be made in the Linda distribution without forcing all users to use ANSI C. Now ANSI C mode can be turned on by setting the environment variable CCOPTS (defined by the HP C compiler) to -Aa, as in:

     etenv CCOPTS -Aa

Alternatively, the shell scripts could be modified to include the -Aa option, as in:

#!/bin/sh
shift
/bin/cc -Aa -tp,${LINDA_PATH}bin/lcpp $*

to always use ANSI mode.

Also, on the HP, linda_cpp uses /lib/cpp by default. You could run into problems unless linda_cpp is modified to use /lib/cpp.ansi. This could be done by modifying linda_cpp, as described in answer 3.5. Perhaps a better solution is to change linda_cpp to use cc with the -E option, as follows:

#!/bin/sh
		input=$1
		output=$2
		shift
		shift

		if [ $# -eq 0 ]
		then
		      /bin/cc -E -I${LINDA_PATH}lib $input > $output
		else
		      /bin/cc -E -I${LINDA_PATH}lib "$@" $input > $output
		fi

Now, the CCOPTS environment variable can be used to turn on ANSI C mode during preprocessing, as well as compiling.

3.8) How do I compile and link C modules with my C-Linda application?

You can just compile .c files with your C compiler, and then link the .o file with the rest of your C-Linda application using clc. There is no reason to rename a pure C file to have a .cl suffix so it can be compiled with clc.

3.9) How do I compile and link Fortran modules with my Fortran-Linda application?

You can just compile .f files with your Fortran compiler, and then link the .o file with the rest of your Fortran-Linda application using flc. There is no reason to rename a pure Fortran file to have a .fl suffix so it can be compiled with flc.

3.10) What is the difference between the "normal" and "underscore" versions of Linda? Why do some architectures have both versions, while others don't?

The answer has to do with conventions for interlanguage calling between C and Fortran.

Usually, C transforms symbols by prepending an "_", so that the symbol "foo" in your program becomes _foo to the loader. The reason for this is to reserve symbol names without underscores for internal use.

Fortran, on the other hand, usually prepends *and* appends an underscore, so "foo" becomes "_foo_".

Since each language is internally consistent, this only becomes an issue when C calls Fortran or vice versa. In that case, all C routines called by Fortran must be named with an appended "_", and all calls by C of Fortran routines must also append an "_". For example:

C:
		foo_()
		{
		 bar_()
		  .....
		}

		Fortran:
		subroutine bar
		begin
		call foo
		....
		end

However, not all Fortran compilers follow this convention, in particular AIX and HP-UX compilers. In these compilers, Fortran symbols do *not* get the appended "_", i.e. they are identical to C symbols. However, in both of these compilers, there is a flag that can be set that forces the "_" convention to be followed. This is nice, because it allows for a consistent and portable C/Fortran interface.

Thus, programmers who are mixing C and Fortran can choose either method: using underscores, which is more portable, or not using underscores, which is more aesthetically pleasing.

Unfortunately, this choice has an impact on the underlying Linda library, which has C/Fortran interfaces of its own. For that reason, we build two separate systems on machines that present this choice. The default system corresponds to the default behavior of the Fortran compiler, i.e. no underscore.

When using the underscore version, *all* Fortran files compiled directly (i.e. not passed to flc) must be compiled with the appropriate flag so that their symbols have "_" appended. In AIX, use
"-qextname"; in HPUX, use "+ppu". Any .f files passed to flc will automatically be compiled with the appropriate flag.

Maintaining two different systems is admittedly cumbersome. In the future, we plan to support both styles with a single system.

TOC, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14