PRO*C MAKE 화일의 비밀

Question

제품 : PRECOMPILERS
작성날짜 : 1995-11-21
Understanding and Modifying Precompiler and OCI Makefiles
Note: This bulletin is also posted under the PCC category (#104220.448).
In order to successfully create a program using the Oracle Precompilers (Pro*C,
Pro*COBOL, Pro*FORTRAN, Pro*Ada, etc.) you need to precompile, compile, and
link your program with the Oracle libraries. On Unix systems, the easiest way
to do this is to use the 'make' utility. Make is a unix command that enables
you to manipulate files automatically. It works by way of a makefile, which is
a file written in a language that 'make' can understand. Oracle provides
makefiles for precompiling, compiling, and linking your programs. They can be
found under the $ORACLE_HOME subdirectory, in
$ORACLE_HOME/proc/demo/proc.mk for Pro*C,
$ORACLE_HOME/procob/demo/procob.mk for Pro*COBOL,
$ORACLE_HOME/profor/demo/profor.mk for Pro*FORTRAN, and
$ORACLE_HOME/proada/demo/proada.mk for Pro*Ada.
All of the makefiles are very similar in terms of the macros that they define,
and how they are used. The remainder of this bulletin will use Pro*C and
proc.mk as an example, but the concepts discussed here are also relevant to the
other languages.
This bulletin is divided into 6 sections and two appendecies:
I. How to use proc.mk for version 1.4, 1.5, and 1.6 of Pro*C
II. How to use proc.mk for version 2.0 of Pro*C
III. How does proc.mk work?
IV. Modifying proc.mk to change the precompile and compile options, and to
add your own libraries
V. Modifying proc.mk for a program which has more than one source module
VI. How to link OCI programs using proc.mk or oracle.mk
VII. Some issues about linking
Appendix A. Source code for the multiple module example
Appendix B. List of useful makefile macros
I. How to use proc.mk for version 1.4, 1.5, and 1.6 of Pro*C
The makefile for these Pro*C versions is set up to create an executable from a
program that is in a single source file. To use it, copy proc.mk from
$ORACLE_HOME/proc/demo into the directory which contains your source code.
This directory also contains electronic versions of the sample programs found
in the "Pro*C Supplement to the Oracle Precompilers Guide". Once you have
copied proc.mk into your directory, you can create your executable by just
typing 'make -f proc.mk <program name>', where <program name> is
the file containing your code, without the .pc extension. For example, if your
code is in my_prog.pc, you would use 'make -f proc.mk my_prog':
unix$ make -f proc.mk my_prog
/u02/7016/bin/proc iname=my_prog.pc ireclen=132 oreclen=132 select_error=no
Pro*C: Release 1.5.10.1.0 - Production on Thu Sep 1 15:09:47 1994
Copyright (c) Oracle Corporation 1979, 1992. All rights reserved.
Precompiling my_prog.pc
/usr/5bin/cc -I. -O -Bdynamic -L/u02/7016/lib -o my_prog my_prog.c /u02/7016/li
b/libsql.a /u02/7016/lib/osntab.o -lsqlnet -lora /u02/7016/lib/libpls.a -lsqlne
t -lnlsrtl -lcv6 -lcore -lnlsrtl -lcv6 -lcore -lm
The above example was done on a Sun with Oracle 7.0.16.6 and Pro*C 1.5.10.1.0.
Your output may look a little different if you are on a different unix system.
After running this command, several files should have been created in the
current directory. my_prog.c is the C output from the precompiler.
my_prog.lis is also generated by the precompiler, and is the listing file that
gives you information about the precompilation. The executable will be called
my_prog.
II. How to use proc.mk for version 2.0 of Pro*C
proc.mk for version 2.0 is much more generic. It is designed to link together
programs that are in multiple modules, without modification. Again, the
makefile itself is found in $ORACLE_HOME/proc/demo, along with the sample
programs. In order to use it for a single module, you would use
'make -f proc.mk EXE=<program name> OBJS=<program name>.o' (after copying
proc.mk to your own directory). For example:
unix$ make -f proc20.mk EXE=my_prog OBJS=my_prog.o
/u03/oracle7.1/bin/proc iname=my_prog.pc
Pro*C: Release 2.0.3.0.0 - Production on Thu Sep 1 15:55:26 1994
Copyright (c) Oracle Corporation 1979, 1994. All rights reserved.
System default option values taken from: /u03/oracle7.1/proc/pmscfg.h
/usr/5bin/cc -I. -O -I/u03/oracle7.1/proc/lib -c my_prog.c
/usr/5bin/cc -Bdynamic -L/u03/oracle7.1/lib -o my_prog my_prog.o -lsql /u03/ora
cle7.1/lib/osntab.o -lsqlnet -lora -lsqlnet -lora -lnlsrtl -lcv6 -lcore -lnls
rtl -lcv6 -lcore `cat /u03/oracle7.1/rdbms/lib/sysliblist`
This will generate the same files as the previous example, plus my_prog.o,
which is an object file containing the compiled form of your code. It is then
linked with the Oracle libraries to create the executable.
III. How does proc.mk work?
To understand proc.mk, first we need to go into some details about how a
makefile works. Makefiles are usually made up of two kinds of entries -
targets and macro definitions.
The general format of a target entry is
<target>: <target1> <target2> ... <targetn>
<command1>
<command2>
<commandm>
Note that there are TABS, not spaces, before each of the <command> lines.
This entry tells make how to create <target> from <target1> through
<targetn>. To do this, make just needs to execute <command1> through
<commandm>. For example, the target entry
my_prog.c: my_prog.pc
proc iname=my_prog.pc ireclen=132 oreclen=132
tells make that to create my_prog.c, if my_prog.pc exists in the current
directory, it just has to run 'proc iname=my_prog.c'. This target rule will be
applied when 'make -f <makefile> my_prog.c' is issued from the unix prompt.
Targets can be chained together as well. For example if you had the target
entry
my_prog.o: my_prog.c
cc -c my_prog.c
in addition to the one above, then make would be able to create my_prog.o from
my_prog.pc by precompiling and compiling. Note that these two entries could
have been combined into
my_prog.o: my_prog.pc
proc iname=my_prog.pc ireclen=132 oreclen=132
cc -c my_prog.c
which would have the same effect.
There are also some special formats for targets, which don't depend on specific
file names. For example, the following sequence of targets creates an object
file from any .pc file:
.SUFFIXES: .pc .c .o
.pc.o:
proc iname=$*.pc ireclen=132 oreclen=132
cc -c $*.c
Note the special syntax here. The .SUFFIXES rule tells make what suffixes
to look for. The .pc.o rule (which has no dependencies) explains how to get
from a .pc file to a .o file. Inside the commands, $* will evaluate to the
filename (without the extension) of whatever file is currently being worked on.
If we put the above example into a file (called example.mk) and run it, we get:
unix$> make -f example.mk my_prog.o
proc iname=my_prog.pc ireclen=132 oreclen=132
Pro*C: Release 1.5.10.1.0 - Production on Mon Sep 19 15:53:22 1994
Copyright (c) Oracle Corporation 1979, 1992. All rights reserved.
Precompiling my_prog.pc
cc -c my_prog.c
unix$
Notice that $* has been replaced with my_prog in the proc and cc commands.
Also note that we had to type 'my_prog.o' on the command line. This is because
the target rule was '.pc.o:'. If it was just '.pc:', then we wouldn't have
needed the .o extension on the command line. But then make wouldn't know that
this command creates a .o file. Make is smart enough to put together a .pc.c
and a .c.o rule to create a .o file from a .pc file.
The other kind of makefile entry is a macro definition. They usually look
like:
MACRONAME=macrotext
This defines the macro MACRONAME to be macrotext. Whenever make sees
$(MACRONAME) (Note the parenthesis), it will be replaced by macrotext. For
example,
PROFLAGS=ireclen=132 oreclen=132
my_prog.c: my_prog.pc
proc iname=my_prog.pc $(PROFLAGS)
will accomplish the same thing as the first example in this section.
'$(PROFLAGS)' will be replaced by 'ireclen=132 oreclen=132' (without the
quotes).
Macros can be defined more than once in a makefile. In that case, the
definition that is last (furthest from the start) will be the one used for the
entire file. Previous definitions are ignored.
IV. Modifying proc.mk to change the precompile and compile options, and to
add your own libraries
NOTE: Be careful of changing too many options, especially the compile and/or
link options. In many cases, changing these to values that are different from
the supplied ones in proc.mk can cause problems. Contact Worldwide Support if
you have questions about any of the compile or link options used in our default
supplied makefiles.
Consider this section of the makefile for Pro*C 1.5.10:
# General suffix rule to build executables from .pc and .c files.
# Usage :
# make -f proc.mk USERID=<user/pass> <prog>
# For example to build an executable from a Pro*C source file named 'abc.pc'
# using scott/tiger for the ORACLE account name. The make command line will
# be:
# make -f proc.mk USERID=scott/tiger abc
# Note: scott/tiger is the default account/password, so that you could
# also use the following command line:
# make -f proc.mk abc
# The executable will be named 'abc'.
.pc:
-$(PROC) iname=$*.pc $(PROFLAGS)
@$(ECHO) $(CC) $(CFLAGS) $(LDFLAGS) -o $* $*.c $(PROLDLIBS)
.c:
@$(ECHO) $(CC) $(CFLAGS) $(LDFLAGS) -o $* $*.c $(PROLDLIBS)
These two target rules tell make how to precompile and compile. See the
previous section for details on how these work. When you run the make, what
actually gets executed are the commands under '.pc:'. The first line is the
precompile, and the second is the compile. If you want to change the
precompiler options, change the PROFLAGS macro. By default, it is set by
PROFLAGS=ireclen=132 oreclen=132 select_error=no $(SQLCHECK) $(PROUSER)
If you want to add the option maxopencursors=20, to change the initial size of
the precompiler cache, you would add it to this line:
PROFLAGS=ireclen=132 oreclen=132 select_error=no maxopencursors=20
Note that I have removed the SQLCHECK and PROUSER macros. They are not
defined by default, so they do not evaluate to anything. You can define them
if you like, which can be used to add additional options such as SQLCHECK and
USERID. See the precompiler manual for more information about the available
precompiler options.
Similarly, you can set compile options with CFLAGS and link options with
LDFLAGS. Appendix B lists other macros used by proc.mk which you may find
useful.
In order to add additional libraries to the link, you can add them to the
PROLDLIBS macro. proc.mk for 1.5.10 (on the Sun) defines this macro as:
PROLDLIBS= $(LIBSQL) $(TTLIBS)
LIBSQL and TTLIBS are other macros previously defined. You can add your own
libraries to this macro to add them to the link:
PROLDLIBS= $(LIBSQL) $(TTLIBS) my_lib1.o my_lib2.o
Better results are obtained if you add your own libraries either after or
before the Oracle libraries. Putting your libraries in between LIBSQL and
TTLIBS can cause undefined symbols.
V. Modifying proc.mk for a program which has more than one source module
Many complicated programs are contained in more than one source module, unlike
the samples. Some of these modules would contain only C functions, and thus
have .c extensions. But the rest would contain embedded SQL as well, and
consequently have .pc extensions. How would you compile and link in a
situation such as this? In the remainder of this section, I present one
solution.
This solution uses the following files, which are included in Appendix A:
File Functions Contained in the File Functions Called by this File
main.c main db_connect, print_names,
db_disconnect
connect.pc db_connect, db_disconnect, none
sqlerror
print_names.pc print_names none
main.h db_connect, db_disconnect,
print_names, sqlerror (This is the header file)
For Pro*C 2.0, proc.mk can compile these together by using the EXE and OBJS
macros. The first target in the makefile (which will be executed if you don't
specify a target on the make line) looks like:
build: $(OBJS)
$(CC) $(LDFLAGS) -o $(EXE) $(OBJS) $(PROLDLIBS)
There are also default rules that tell make how to get from a .pc file to a .o
file:
.SUFFIXES: .exe .o .c .pc
.pc.c:
$(PROC) $(PROFLAGS) iname=$*.pc
.pc.o:
$(PROC) $(PROFLAGS) iname=$*.pc
$(CC) $(CFLAGS) $(PROCINC) -c $*.c
.c.o:
$(CC) $(CFLAGS) $(PROCINC) -c $*.c
So you can define the EXE macro to be the name of the executable, and the OBJS
macro to be the object files used. You can either do this in the makefile
itself (and then run it with 'make -f proc.mk') or, define them on the command
line. To compile the example, use:
make -f proc.mk EXE=main OBJS="connect.o print_names.o main.o"
Note the double quotes around the object lists. This is to pass the spaces as
part of the macro.
For Pro*C 1.5, consider the following, which should be added to the end of the
makefile:
OBJECTS=main.o print_names.o connect.o
main: $(OBJECTS)
@$(ECHO) $(CC) $(CFLAGS) -o main $(OBJECTS) $(PROLDLIBS) \\
$(CLIBS)
main.o: main.c main.h
@$(ECHO) $(CC) $(CFLAGS) -c main.c
connect.o: connect.pc main.h
@$(ECHO) $(PROC) iname=connect.pc $(PROFLAGS)
@$(ECHO) $(CC) $(CFLAGS) -c connect.c
print_names.o: print_names.pc main.h
@$(ECHO) $(PROC) iname=print_names.pc $(PROFLAGS)
@$(ECHO) $(CC) $(CFLAGS) -c print_names.c
If you are not on a Sun as I am, the commands under connect.o and print_names.o
should be the same as those under the '.pc:' target. Under main.o, the command
should be the same as that under '.c:'. Compare the commands given here to
those from my proc.mk, shown at the beginning of section IV.
Again note that there are TABS, not spaces, before the command lines for
precompilation and compilation, in accordance with the makefile format. With
the above lines added to the end of proc.mk, we can create the executable by
issuing 'make -f proc.mk main'. The output I get when running for the first
time (no additional files beyond the original 4 exist) is:
technique /home/csupport/surman/make> make -f proc.mk main
/usr/5bin/cc -I. -O -c main.c
/u02/7016/bin/proc iname=print_names.pc ireclen=132 oreclen=132 select_error=no
Pro*C: Release 1.5.10.1.0 - Production on Wed Sep 21 17:37:02 1994
Copyright (c) Oracle Corporation 1979, 1992. All rights reserved.
Precompiling print_names.pc
/usr/5bin/cc -I. -O -c print_names.c
/u02/7016/bin/proc iname=connect.pc ireclen=132 oreclen=132 select_error=no
Pro*C: Release 1.5.10.1.0 - Production on Wed Sep 21 17:37:06 1994
Copyright (c) Oracle Corporation 1979, 1992. All rights reserved.
Precompiling connect.pc
/usr/5bin/cc -I. -O -c connect.c
/usr/5bin/cc -I. -O -o main main.o print_names.o connect.o /u02/7016/lib/libsql
.a /u02/7016/lib/osntab.o -lsqlnet -lora /u02/7016/lib/libpls.a -lsqlnet -lnlsr
tl -lcv6 -lcore -lnlsrtl -lcv6 -lcore -lm -lm
After running as above, a number of additional files are created. The
files connect.lis and print_names.lis are generated by the
precompiler, along with connect.c and print_names.c. Each of the .c
files is then compiled with the '-c' option to create a .o file. So
we get main.o, connect.o, and print_names.o. Finally, the object
files are linked together to form the final executable, which is
called 'main'.
What are all these files? The .c extension signifies a file
containing pure C code. The main program is in main.c to start with.
The .pc extension signifies a file containing C code with embedded
SQL, suitable for precompiling. The precompiler generates the .c file
from the .pc file. The .lis extension signifies a listing file, also
generated by the precompiler. It contains a trace of the
precompilation attempt. Files with the .o extension are library
files. They contain compiled code, and can be linked together into
one executable. Different compilers can generate .o files, created
from source files written in different languages. All of the .o files
can be linked together, regardless of the original source language.
main.h is the header file. This contains external definitions for
the functions referenced by each module. This is necessary so the compiler
will understand the correct prototype for each function. Note that
it is referenced on the target line for each file. This is so
the files are recompiled when the header file is changed.
The linking is done by the final cc command, located under the make
target main:
@$(ECHO) $(CC) $(CFLAGS) -o main $(OBJECTS) $(PROLDLIBS) \\
$(CLIBS)
The only new thing here is the -o option. This is an option to the
cc command which tells the compiler the name of the output file. In
this case, it is called 'main'. If no output file is specified, the
compiler usually calls it 'a.out'.
Using this method has the advantage that make will only compile those files
which need to be changed. For example, consider the main target:
main: $(OBJECTS)
@$(ECHO) $(CC) $(CFLAGS) -o main $(OBJECTS) $(PROLDLIBS) \\
$(CLIBS)
Whenever one of $(OBJECTS) (in this case, the object files created
by compilation) has changed, make will run the commands under this
target (in this case, the link command).
What this means is that only those files which have been changed will
be recompiled. If you change print_names.pc (try "touch print_names.pc"
from the unix prompt) and run make, you will get only:
unix$ touch print_names.pc
unix$ make -f proc.mk main
/u02/7016/bin/proc ireclen=132 oreclen=132 select_error=no iname=print_names.pc
Pro*C: Release 1.5.10.1.0 - Production on Wed Sep 21 17:48:48 1994
Copyright (c) Oracle Corporation 1979, 1992. All rights reserved.
Precompiling print_names.pc
/u02/7016/bin/proc iname=print_names.pc ireclen=132 oreclen=132 select_error=no
Pro*C: Release 1.5.10.1.0 - Production on Wed Sep 21 17:48:50 1994
Copyright (c) Oracle Corporation 1979, 1992. All rights reserved.
Precompiling print_names.pc
/usr/5bin/cc -I. -O -c print_names.c
/usr/5bin/cc -I. -O -o main main.o print_names.o connect.o /u02/7016/lib/libsql
.a /u02/7016/lib/osntab.o -lsqlnet -lora /u02/7016/lib/libpls.a -lsqlnet -lnlsr
tl -lcv6 -lcore -lnlsrtl -lcv6 -lcore -lm -lm
unix$
Notice that the only thing that was done here was to precompile and
compile print_names.pc, generating print_names.o. Then, since main
depends on print_names.o, the final cc command (which links the final
executable) was also done. So the same make command will only
recompile those modules which have changed. This can be significant
when linking in many modules, some of which can take a long time to
compile. For more information on the make command, I suggest that you
look at a Unix or make manual. One such book is "Managing Projects
with Make", by Andrew Oram and Steve Talbott.
Note that you can create suffix rules for the proc.mk for 1.5, similar to the
ones for Pro*C 2.0. By using suffix rules, it is possible to shorten this
example. The commands for each of the .pc files are identical. Rather
than having a separate entry for each one, you can create general
suffix rules that tell make how to create a .o file from a .pc file, for
example. For more information on how to do this, I recommend that you
consult a book or tutorial on make, such as the book referenced above.
VI. How to link OCI programs using proc.mk or oracle.mk
The libraries used to link OCI programs are very similar to the libraries used
to link Pro*C programs. The main difference is that OCI programs link with
libocic.a, and Pro*C programs link with libsql.a. Both can be found under
$ORACLE_HOME/lib for Oracle7, and $ORACLE_HOME/rdbms/lib for version 6.
For Oracle7, you can use either proc.mk or oracle.mk to link OCI code.
oracle.mk is a makefile found in $ORACLE_HOME/rdbms/lib, and is used mainly for
linking various options into the Oracle RDBMS itself, as well as for linking
the Oracle executables. There are also targets in oracle.mk which will link
the sample OCI programs cdemo1.c through cdemo3.c. Following are these
targets, taken from the oracle.mk for 7.0.16 on Sun:
OCILDLIBS= $(LIBOCIC) $(TTLIBS) $(LLIBCORE)
INCLUDE= -I$(ORACLE_HOME)/rdbms/demo
MAKEDEMO= \\
@if [ "$(NONDEFER)" = "true" -o "$(NONDEFER)" = "TRUE" ] ; then \\
$(ECHO) $(CC) $(LDFLAGS) -o $@ $? $(NDFOPT) $(OCILDLIBS) $(CLIBS); \\
else \\
$(ECHO) $(CC) $(LDFLAGS) -o $@ $? $(OCILDLIBS) $(CLIBS); \\
fi
cdemo1: cdemo1.o
$(MAKEDEMO)
.c.o:
$(CC) -c $(INCLUDE) $(CFLAGS) $*.c
First note the '.c.o' target rule. Note that the INCLUDE macro is here, which
has the -I compiler option to include the directory where the demo header files
are located. The cdemo1 target will execute the MAKEDEMO macro. Based on
whether or not the NONDEFER macro is "true" or "TRUE", the program is linked
either with or without the nondeferred option. Notice that if NONDEFER is true,
then the NDFOPT macro is included in the link. If NONDEFER isn't true, then
NDFOPT isn't included. That's the only difference. If you link with the
nondeferred option, than deferring the parse with the defflg parameter of
oparse() has no effect. See the OCI manual for more information on the
oparse() function and what it does. In most cases, you will want the ability
to defer the parse, and so you wouldn't link with NDFOPT. Other than NDFOPT,
the libraries to link with are OCILDLIBS and CLIBS. So you can use these
macros in your own makefile to link OCI programs.
proc.mk can also be used to link OCI programs. Like oracle.mk, it also defines
OCILDLIBS. The link line would look like the line under the .pc: target used
for Pro*C programs, but would use OCILDLIBS instead of PROLDLIBS:
@$(ECHO) $(CC) $(CFLAGS) $(LDFLAGS) -o $* $*.c $(OCILDLIBS)
Note that proc.mk does not link with the nondeferred option. For version 6,
there are no OCI targets in oracle.mk, so you should use proc.mk as the
template to link OCI programs. For Oracle7, use either proc.mk or oracle.mk.
VII. Some issues about linking
Most unix linkers are one-pass. This means that the linker will only examine
the symbols in your executable once. Because of this, several of the Oracle
libraries need to be included more than once to resolve all of the symbols.
This is because the libraries are mutually referencial - functions in one
library call functions in another, and the second library in turn calls
functions in the first library. As a result, it is not recommended that you
change the order of the libraries in the link. If you add your own libraries,
add them either before or after the Oracle libraries. Don't put them between
Oracle libraries on the link line. The Oracle libraries would be PROLDLIBS for
Pro*C programs, and OCILDLIBS for OCI programs. If you use a utility such as
'nmake', you should be aware of how that differs from 'make', as well. Macro
processing can be different between the two utilities.
You should also be aware that the specific Oracle libraries used vary between
operating systems and Oracle versions. If you upgrade the precompiler and the
database, chances are that the libraries necessary will also change. So you
may have to change any existing makefiles. Always use the proc.mk that ships
with the precompiler as a guide to which libraries are necessary.
There are two different ways to specify a library to be included in the link.
One is to fully qualify the name of the library (such as /u02/7016/lib/libsql.a
in the above example). Another is to use the -l option. If you specify a
library (such as -lnlsrtl) this tells the linker to look for a library called
libnlsrtl.a in the library search path. To add directories to the library
search path, use the -L option. For example, the LDFLAGS macro should contain
-L$(ORACLE_HOME)/lib. This tells the linker to look in this directory to find
libraries specified with -l. Some of the Oracle libraries are fully qualified,
and some are included with -L and -l. Both have the same effect.
You can create your own libraries by using the 'ar' unix command. This utility
allows you to archive several .o object files into one .a library archive.
Consult your unix man pages on 'ar' for more information on this command and
how to use it.
Appendix A: Source code for the multiple module example
Here are the files used in this example:
**** FILE main.h ****
extern void sqlerror();
extern void connect();
extern void print_names();
extern void disconnect();
*** FILE main.c ****
#include <stdio.h>
#include "main.h"
void main() {                                                                 
int dept;
printf("Hello There!\
printf("Now connecting...\
connect("scott", "tiger");
printf("Enter dept no: ");
scanf("%d", &dept);
print_names(dept);
printf("Disconnecting...\
disconnect();
**** FILE connect.pc ****
#include <stdio.h>
#include "main.h"
EXEC SQL include sqlca;
void connect(username, password)
char *username;                                                                
char *password;  {                                                             
EXEC SQL begin declare section;
VARCHAR un[20];
VARCHAR pw[20];
EXEC SQL end declare section;
strcpy(un.arr, username);
un.len = strlen(un.arr);
strcpy(pw.arr, password);
pw.len = strlen(pw.arr);
EXEC SQL whenever sqlerror do sqlerror();
EXEC SQL connect :un identified by :pw;
void disconnect() {                                                           
EXEC SQL commit work release;
void sqlerror() {                                                              
printf("SQL error!!\
EXEC SQL whenever sqlerror continue;
printf("% .70s \
",sqlca.sqlerrm.sqlerrmc);
EXEC SQL rollback release;
exit(1);
**** FILE print_names.pc ****
#include <stdio.h>
#include "main.h"
EXEC SQL include sqlca;
EXEC SQL begin declare section;
VARCHAR ename[20];
EXEC SQL end declare section;
void print_names(dept)
EXEC SQL begin declare section;
int dept;
EXEC SQL end declare section; {                                               
EXEC SQL whenever sqlerror do sqlerror();
EXEC SQL DECLARE emp_cursor CURSOR FOR
select ename
from emp
where deptno = :dept;
EXEC SQL OPEN emp_cursor;
EXEC SQL whenever not found goto done_loop;
printf("Employees in dept %d:\
", dept);
for (;;) {                                                                   
EXEC SQL fetch emp_cursor into :ename;
ename.arr[ename.len] = '\\0';
printf("%s\
", ename.arr);
done_loop:
EXEC SQL CLOSE emp_cursor;
Appendix B. List of useful makefile macros
Note that many of these macros are defined, but not all of them. proc.mk for
Pro*C 2.0, for example, uses PROFLAGS in the precompile targets, but does not
define it.
PROFLAGS: options to be passed to the precompiler, such as ireclen or
sqlcheck
CFLAGS: options to be passed to the compiler, such as -I or -O
LDFLAGS: options to be passed to the linker, such as -L
CC (or RCC): the C compiler (/usr/5bin/cc for Sun)
PROC: the precompiler ($ORACLE_HOME/bin/proc)
LIBHOME: directory in which to find the Oracle libs ($ORACLE_HOME/lib for
Oracle7, $ORACLE_HOME/rdbms/lib for version 6)
LIBxxx: Oracle library libxxx.a fully qualified (such as LIBSQL, equal to
$(LIBHOME)/libsql.a)
LLIBxxx: Oracle library libxxx.a, using -l (such as LLIBCORE, equal to
-lcore)
PROLDLIBS: Oracle libraries necessary to link (defined in terms of other
macros)
OCILDLIBS: Oracle libraries necessary to link programs using the Oracle
Call Interfaces (OCI) (also defined in terms of other macros)
______________________________________________________________________________

Answer 1

Robert B     gin (self) (guest) wrote:
: Robert B     gin (guest) wrote:
: : Since I've last posted, I've installed RedHat 5.2 and
ditched
: : Slackware!
: : (btw, what a breeze - Hat's off to RH! very nice install!).
: : I've then installed oracle, have managed to setup
tnsnames.ora
: : so I can connect via sqlplus to my remote database (on
: VAX/VMS).
: : But now I have Pro*C linker problems with:
: : make -f demo_proc.mk build OBJS=test.o exe=test
: : (blah,blah,blah)
: : /usr/lib/crt1.o(.text+0x36): undefined reference to `main'
: : make: *** [build] Error 1
: : Does anybody out there have a similar problem?
: : Rob
: Duh! forget it... (EXE has to be caps... RTFM)
: (cryptic error message though?)
: works great!!!
Could you please tell me where I can get demo_proc.mk file
for Linux (RedHat)?
Thanks
null