Newsgroups: comp.sys.apple2.programmer Path: blue.weeg.uiowa.edu!news.uiowa.edu!uunet!comp.vuw.ac.nz!actrix.gen.nz!dempson From: dempson@atlantis.actrix.gen.nz (David Empson) Subject: Re: Library files in ORCA Message-ID: Nntp-Posting-Host: atlantis.actrix.gen.nz Sender: news@actrix.gen.nz (News Administrator) Organization: Actrix - New Zealand Internet Service Providers Date: Mon, 12 Dec 1994 14:05:58 GMT References: Lines: 186 In article , RKE wrote: > What is the proper way to get ORCA/C (or pascal for that matter) to use > library files? I'm trying to port some files to the GS but I can't seem > to get the libraries to load. For example my source code #includes > stdio.h. It's one of the (object) files in orcalib. Whoa! You have some rather major concepts confused somewhere. "stdio.h" is not a library, or an object file. It is a header file (in the 13/orcacdefs directory) which contains definitions and declarations for macros, types, variables and functions that are used for standard I/O operations. The functions defined in stdio.h happen to be in one of the libraries in prefix 13 (orcalib, in this case), but there is no specific connection between the library and this header file. Other header files also refer to functions in the same library file. With all C compilers, you can include header files in two ways: #include "filename.h" Looks for the header file in the current directory. If it cannot be found there, look in the "standard places", which are system specific. Some C compilers offer a search path for header files. In the case of ORCA/C, the last place the compiler looks for the header file is the directory 13/orcacdefs. #include Same as above, but only look in the "standard places" and don't try looking in the current directory. Assuming you are porting a multi-file program from another platform, you may have a program that has been structured as several C files, with header files for some of them, defining entry points, etc. In this case, you would normally compile each C file separately (you can specify all the names on the same compile command line) or use a make utility or shell command file to automatically compile them. Each source file may include one or more header files defining entry points in other source files. When compiled, each source file will produce an object file in the current directory. You should add the following line near the start of all C source files (not header files) except the one containing the main function. #pragma noroot This tells ORCA/C not to create a .ROOT file for each source file. Alternatively, you can delete all of the extra .ROOT files before linking. You only need one .ROOT file, which contains the startup code for the program. Extra .ROOT files will not cause any problems - they will just waste space in the executable. The final step is to link all the files together. You do this with a single link command, listing all of the modules. They only significant requirement is that the module with the .ROOT file must come first in the list of modules. Here is a simple example. My DESCII program consists of the following source files. descii.c Mainline and glue code binscii.c BinSCII encoding and decoding routines binfile.c Binary file access routines textfile.c Text file access routines summary.c Summary report generation Each source file except descii.c has a "#pragma noroot" line. There is one header file that is included by all source files. It declares all of the externally accessible functions, major data structures, etc. binscii.h I can compile all of the source files using: compile descii.c binscii.c binfile.c textfile.c summary.c keep=$ Assuming no compile errors, I end up with the following object files: descii.root descii.a binscii.a binfile.a textfile.a summary.a I can then link them to produce an executable by using the following command: link descii binscii binfile textfile summary keep=descii The final executable file is called descii. Now, it is possible to create your own libraries, and place them in prefix 13. I've done this with a set of routines I use in most programs, for doing things like reading the keyboard, checking for Apple-period, command line parsing for assembly language programs, etc. All of the routines are written in assembly language, but this is incidental. I used the makelib utility to combine all of the object files (one for each utility function) into one library called "mylib", which I then copied into prefix 13 (arranging things so that it would appear in the directory before ORCA's libraries, so my library is searched first). Now I can automatically use any of the functions in mylib by using an appropriate declaration in the source file. The linker automatically calls in the appropriate routines without my having to list them explicitly. One point that may be confusing you: you cannot put object files in prefix 13 and expect to have them linked in automatically when required. You have to turn them into a library, using makelib. You also asked about Pascal. In ORCA/Pascal, the concepts are pretty similar. The definitions for the standard Pascal functions (listed in the ORCA/Pascal manual) are built into the compiler, and the code for these functions is included in 13/paslib and 13/syslib. For the toolbox and GS/OS calls, there is a unit for each toolset. The units contain an interface, but the implementation part is empty. All of the tool calls are declared using a special directive. Once the unit is compiled, ORCA/Pascal produces a binary file called something.INT (for INTERFACE). This file can be placed in the 13/orcapascaldefs directory, which is where the compiler expects to find all units (it checks the current directory first). Since there is no implementation code for these units, no object file is created. If you have a multi-part Pascal program (several units and a PROGRAM), the units are compiled first, producing .INT (interface) and .A (object) files. The interface files should be left in the current directory. When you compile the program (or one unit which uses another), the .INT file is required by the compiler. Compiling the program will produce .ROOT and .A object files. The final step is to link the parts together. The program is listed first, followed by each of the units. If you have a frequently used unit, the object file can be placed in a library, again using MAKELIB, and the library should then be placed in prefix 13. The .INT file should be copied into 13/orcapascaldefs, so you can use it from any directory. The resulting unit can be used transparently. If you want to access an object file written in another language (but with Pascal calling conventions), all that is required is a unit which declares all of the procedures and functions in the object file (in the interface part), with "extern;" directives to tell the compiler that the procedures and functions are not defined in this file. (I can't recall off-hand whether the "extern;" directive should go in the interface part, or in the implementation part.) When compiled, the unit will produce a .INT file, which can be used as before (either in the current directory, or copy it to 13/orcapascaldefs). I think I've covered the major points. There are a few extra features, for example with ORCA/C 2.x you can specify a search path for include files (headers). You can also have libraries in directories other than prefix 13, and explicitly link them, or use the "Libraries" shell variable to specify a list of libraries to search instead of all the libraries in prefix 13. Any more details you need, or points that need clarifying? -- David Empson dempson@actrix.gen.nz Snail mail: P.O. Box 27-103, Wellington, New Zealand