]>
Commit | Line | Data |
---|---|---|
071cd279 | 1 | 1 GCC |
2 | ||
3 | The GCC command invokes the GNU C compiler. | |
4 | ||
5 | GCC file-spec | |
6 | ||
7 | 2 Parameters | |
8 | ||
9 | file-spec | |
10 | ||
11 | A C source file. If no input file extension is specified, GNU C | |
12 | assumes .C as the default extension unless the /PLUS qualifier is | |
13 | given, in which case .CC is assumed as the default extension. | |
14 | ||
15 | If an extension of .CPP is given, then the source file is assumed to | |
16 | be the output of the preprocessor, and thus the preprocessor is not | |
17 | executed. | |
18 | ||
19 | If an extension of .S is given, then the source file is assumed to be | |
20 | the assembly code output of the compiler, and only the assembler is | |
21 | called to generate an object file. | |
22 | ||
23 | 2 Qualifiers | |
24 | ||
25 | GNU C command qualifiers modify the way the compiler handles the | |
26 | compilation. | |
27 | ||
28 | The following is the list of available qualifiers for GNU C: | |
29 | ||
30 | /CASE_HACK | |
31 | /CC1_OPTIONS=(option [,option...]]) | |
32 | /DEBUG | |
33 | /DEFINE=(identifier[=definition][,...]) | |
34 | /G_FLOAT | |
35 | /INCLUDE_DIRECTORY=(path [,path...]]) | |
36 | /LIST[=filename] | |
37 | /MACHINE_CODE | |
38 | /OBJECT[=filename] | |
39 | /OPTIMIZE | |
40 | /PLUS | |
41 | /PROFILE[=identifier] | |
42 | /SCAN=(file[,file...]) | |
43 | /SHOW[=option] | |
44 | /UNDEFINE=(identifier[,identifier,...]) | |
45 | /VERBOSE | |
46 | /VERSION | |
47 | /WARNING | |
48 | ||
49 | 2 Linking | |
50 | ||
51 | When linking programs compiled with GNU C, you should include the GNU | |
52 | C library before the VAX C library. For example, | |
53 | ||
54 | LINK object-file,GNU_CC:[000000]GCCLIB/LIB,SYS$LIBRARY:VAXCRTL/LIB | |
55 | ||
56 | You can also link your program with the shared VAX C library. This | |
57 | can reduce the size of the .EXE file, as well as make it smaller when | |
58 | it's running. For example, | |
59 | ||
60 | $ LINK object-file, GNU_CC:[000000]GCCLIB/LIB,SYS$INPUT/OPT | |
61 | SYS$SHARE:VAXCRTL/SHARE | |
62 | ||
63 | (If you use the second example and type it in by hand, be sure to | |
64 | type ^Z after the last carriage return). A simpler alternative would | |
65 | be to place the single line: | |
66 | ||
67 | SYS$SHARE:VAXCRTL/SHARE | |
68 | ||
69 | into a file called VAXCRTL.OPT, and then use the link command: | |
70 | ||
71 | $ LINK object-file, GNU_CC:[000000]GCCLIB/LIB,VAXCRTL.OPT/OPT | |
72 | ||
73 | If a program has been compiled with /G_FLOAT, then the linking | |
74 | instructions are slightly different. If you are linking with the | |
75 | non-shared library, then the command that you should use would be: | |
76 | ||
77 | LINK object-file,GNU_CC:[000000]GCCLIB/LIB,SYS$LIBRARY:VAXCRTLG/LIB - | |
78 | ,SYS$LIBRARY:VAXCRTL/LIB | |
79 | ||
80 | Note that both VAXCRTL and VAXCRTLG must be linked to. If you are | |
81 | using the shared VAX C library, then you should use a command like: | |
82 | ||
83 | $ LINK object-file, GNU_CC:[000000]GCCLIB/LIB,SYS$INPUT:/OPTIONS | |
84 | SYS$SHARE:VAXCRTLG/SHARE | |
85 | ||
86 | In the case of the sharable library, only one library needs to be | |
87 | linked to. | |
88 | ||
071cd279 | 89 | 2 /CASE_HACK |
90 | ||
91 | /[NO]CASE_HACK D=/CASE_HACK | |
92 | ||
93 | Since the VMS Linker and Librarian are not case sensitive with | |
94 | respect to symbol names, a "case-hack" is appended to a symbol name | |
95 | when the symbol contains upper case characters. | |
96 | ||
97 | There are cases where this is undesirable, (mainly when using certain | |
98 | applications where modules have been precompiled, perhaps in another | |
99 | language) and we want to compile without case hacking. In these | |
100 | cases the /NOCASE_HACK switch disables case hacking. | |
101 | ||
102 | 2 /CC1_OPTIONS | |
103 | ||
104 | This specifies additional switches to the compiler itself which | |
105 | cannot be set by means of the compiler driver. | |
106 | ||
107 | 2 /DEBUG | |
108 | ||
109 | /DEBUG includes additional information in the object file output so | |
110 | that the program can be debugged with the VAX Symbolic Debugger. | |
111 | ||
112 | To use the debugger it is also necessary to link the debugger to your | |
113 | program, which is done by specifying the /DEBUG qualifier to the link | |
114 | command. With the debugger it is possible to set breakpoints, | |
115 | examine variables, and set variables to new values. See the VAX | |
116 | Symbolic Debugger manual for more information, or type "HELP" from | |
117 | the debugger prompt. | |
118 | ||
119 | 2 /DEFINE | |
120 | ||
121 | /DEFINE=(identifier[=definition][,...]) | |
122 | ||
123 | /DEFINE defines a string or macro ('definition') to be substituted | |
124 | for every occurrence of a given string ('identifier') in a program. | |
125 | It is equivalent to the #define preprocessor directive. | |
126 | ||
127 | All definitions and identifiers are converted to uppercase unless | |
128 | they are in quotation marks. | |
129 | ||
130 | The simple form of the /DEFINE qualifier: | |
131 | ||
132 | /DEFINE=vms | |
133 | ||
134 | results in a definition equivalent to the preprocessor directive: | |
135 | ||
136 | #define VMS 1 | |
137 | ||
138 | You must enclose macro definitions in quotation marks, as in this | |
139 | example: | |
140 | ||
141 | /DEFINE="C(x)=((x) & 0xff)" | |
142 | ||
143 | This definition is the same as the preprocessor definition: | |
144 | ||
145 | #define C(x) ((x) & 0xff) | |
146 | ||
147 | If more than one /DEFINE is present on the GCC command line, only the | |
148 | last /DEFINE is used. | |
149 | ||
150 | If both /DEFINE and /UNDEFINE are present on a command line, /DEFINE | |
151 | is evaluated before /UNDEFINE. | |
152 | ||
153 | 2 /G_FLOAT | |
154 | ||
155 | Instructs the compiler to use "G" floating point arithmetic instead | |
156 | of "D". The difference is that double precision has a range of | |
157 | approximately +/-0.56e-308 to +/-0.9 e+308, with approximately 15 | |
158 | decimal digits precision. | |
159 | ||
160 | "D" floating point has the same range as single precision floating | |
161 | point, with approximately 17 decimal digits precision. | |
162 | ||
163 | If you use the /G_FLOAT qualifier, the linking instructions are | |
164 | different. See "Linking" for further details. | |
165 | ||
166 | 2 /LIST | |
167 | ||
168 | /LIST[=list_file_name] | |
169 | ||
170 | This does not generate a listing file in the usual sense, however it | |
171 | does direct the compiler to save the preprocessor output. If a file | |
172 | is not specified, then this output is written into a file with the | |
173 | same name as the source file and an extension of .CPP. | |
174 | ||
175 | 2 /INCLUDE_DIRECTORY | |
176 | ||
177 | /INCLUDE_DIRECTORY=(path [,path...]) | |
178 | ||
179 | The /INCLUDE_DIRECTORY qualifier provides additional directories to | |
180 | search for user-defined include files. 'path' can be either a | |
181 | logical name or a directory specification. | |
182 | ||
183 | There are two forms for specifying include files - #include | |
184 | "file-spec" and #include <file-spec>. For the #include "file-spec" | |
185 | form, the search order is: | |
186 | ||
187 | 1. The directory containing the source file. | |
188 | ||
189 | 2. The directories in the /INCLUDE qualifier (if any). | |
190 | ||
191 | 3. The directory (or directories) specified in the logical name | |
192 | GNU_CC_INCLUDE. | |
193 | ||
194 | 4. The directory (or directories) specified in the logical name | |
195 | SYS$LIBRARY. | |
196 | ||
197 | For the #include <file-spec> form, the search order is: | |
198 | ||
199 | 1. The directories specified in the /INCLUDE qualifier (if any). | |
200 | ||
201 | 2. The directory (or directories) specified in the logical name | |
202 | GNU_CC_INCLUDE. | |
203 | ||
204 | 3. The directory (or directories) specified in the logical name | |
205 | SYS$LIBRARY. | |
206 | ||
207 | 2 /MACHINE_CODE | |
208 | ||
209 | Tells GNU C to output the machine code generated by the compiler. | |
210 | The machine code is output to a file with the same name as the input | |
211 | file, with the extension .S. An object file is still generated, | |
212 | unless /NOOBJ is also specified. | |
213 | ||
214 | 2 /OBJECT | |
215 | ||
216 | /OBJECT[=filename] | |
217 | /NOOBJECT | |
218 | ||
219 | Controls whether or not an object file is generated by the | |
220 | compiler. | |
221 | ||
222 | 2 /OPTIMIZE | |
223 | ||
224 | /[NO]OPTIMIZE | |
225 | ||
226 | Controls whether optimization is performed by the compiler. By | |
227 | default, optimization is on. /NOOPTIMIZE turns optimization off. | |
228 | ||
229 | 2 /PLUS | |
230 | ||
231 | Instructs the compiler driver to use the GNU-C++ compiler instead of | |
232 | the GNU-C compiler. Note that the default extension of source files | |
233 | is .CC when this qualifier is in effect. | |
234 | ||
235 | 2 /PROFILE | |
236 | ||
237 | /PROFILE[=identifier] | |
238 | ||
239 | Instructs the compiler to generate function profiling code. You must | |
240 | link your program to the profiler when you use this options. The | |
241 | profile statistics are automatically printed out on the terminal | |
242 | during image exit. (i.e. no modifications to your source file are | |
243 | required in order to use the profiler). | |
244 | ||
245 | There are three identifiers that can be used with the /PROFILE | |
246 | switch. These are ALL, FUNCTION, and BLOCK. If /PROFILE is given | |
247 | without an identifier, then FUNCTION is assumed. | |
248 | ||
249 | 3 Block_Profiler | |
250 | ||
251 | The block profiler counts how many times control of the program | |
252 | passes certain points in your program. This is useful in determining | |
253 | which portions of a program would benefit from recoding for | |
254 | optimization. | |
255 | ||
256 | The report for the block profiler contains the function name, file | |
257 | name, PC, and the source file line number as well as the count of how | |
258 | many times control has passed through the specified source line. | |
259 | ||
260 | 3 Function_Profiler | |
261 | ||
262 | The function profiler counts how many times each function is entered, | |
263 | and keeps track of how much CPU time is used within each function. | |
264 | ||
265 | You should be careful about interpreting the results of profiles | |
266 | where there are inline functions. When a function is included as | |
267 | inline, then there is no call to the internal data collection routine | |
268 | used by the profiler, and thus there will be no record of this | |
269 | function being called. The compiler does generate a callable version | |
270 | of each inline function, and if this called version is used, then the | |
271 | profiler's data collection routine will be called. | |
272 | ||
273 | 2 /SCAN | |
274 | ||
275 | /SCAN=(file[,file...]) | |
276 | ||
277 | This qualifier supplies a list of files that will be read as input, | |
278 | and the output will be discarded before processing the regular input | |
279 | file. Because the output generated from the files is discarded, the | |
280 | only effect of this qualifier is to make the macros defined in the | |
281 | files available for use in the main input. | |
282 | ||
283 | 2 /SHOW | |
284 | ||
285 | /SHOW[=option] | |
286 | ||
287 | This causes the preprocessor to generate information other than the | |
288 | preprocessed input file. When this qualifier is used, no assembly | |
289 | code and no object file is generated. | |
290 | ||
291 | The output of the preprocessor is placed in the file specified by the | |
292 | /LIST qualifier, if present. If the /LIST qualifier is not present, | |
293 | then the output is placed in a file with the same name as the input | |
294 | file with an extension that depends upon which option that is | |
295 | selected. | |
296 | ||
297 | 3 DEFINITIONS | |
298 | ||
299 | This option causes the preprocessor to dump a list of all of the | |
300 | definitions to the output file. This is useful for debugging | |
301 | purposes, since it lets you determine whether or not everything has | |
302 | been defined properly. | |
303 | ||
304 | If the default file name is used for the output, the extension will | |
305 | be .DEF. | |
306 | ||
307 | 3 RULES | |
308 | ||
309 | This option causes the preprocessor to output a rule suitable for | |
310 | MAKE, describing the dependencies of the main source file. The | |
311 | preprocessor outputs one MAKE rule containing the object file name | |
312 | for that source file, a colon, and the names of all the concluded | |
313 | files. If there are many included files then the rule is split into | |
314 | several lines using the '\'-newline. | |
315 | ||
316 | When using this option, only files included with the "#include "file" | |
317 | directive are mentioned. | |
318 | ||
319 | If the default file name is used for the output, a null extension | |
320 | will be used. | |
321 | ||
322 | 3 ALL | |
323 | ||
324 | This option is similar to RULES, except that it also mentions files | |
325 | included with the "#include <file.h>" directive. | |
326 | ||
327 | If the default file name is used for the output, a null extension | |
328 | will be used. | |
329 | ||
330 | 2 /UNDEFINE | |
331 | ||
332 | /UNDEFINE cancels a macro definition. Thus, it is the same as the | |
333 | #undef preprocessor directive. | |
334 | ||
335 | If more than one /UNDEFINE is present on the GCC command line, only | |
336 | the last /UNDEFINE is used. | |
337 | ||
338 | If both /DEFINE and /UNDEFINE are present on a command line, /DEFINE | |
339 | is evaluated before /UNDEFINE. | |
340 | ||
341 | 2 /VERBOSE | |
342 | ||
343 | Controls whether the user sees the invocation command strings for the | |
344 | preprocessor, compiler, and assembler. The compiler also outputs | |
345 | some statistics on time spent in its various phases. | |
346 | ||
347 | 2 /VERSION | |
348 | ||
349 | Causes the preprocessor and the compiler to identify themselves by | |
350 | their version numbers, and in the case of the compiler, the version | |
351 | number of the compiler that built it. | |
352 | ||
353 | 2 /WARNING | |
354 | ||
355 | When this qualifier is present, warnings about usage that should be | |
356 | avoided are given by the compiler. For more information, see "Using | |
f12b58b3 | 357 | and Porting the GNU Compiler Collection (GCC)", in the section on |
358 | command line options, under "-Wall". | |
071cd279 | 359 | |
360 | Warnings are also generated by the preprocessor when this qualifier | |
361 | is given. | |
362 | ||
363 | 2 Known_Incompatibilities_with_VAX-C | |
364 | ||
365 | There are several known incompatibilities between GNU-C and VAX-C. | |
366 | Some common ones will be briefly described here. A complete | |
f12b58b3 | 367 | description can be found in "Using and Porting the GNU Compiler |
368 | Collection (GCC)" in the chapter entitled "Using GCC on VMS". | |
071cd279 | 369 | |
370 | GNU-C provides case hacking as a means of giving case sensitivity | |
371 | to symbol names. The case hack is a hexadecimal number appended to | |
372 | the symbol name, with a bit being set for each upper case letter. | |
373 | Symbols with all lower case, or symbols that have a dollar sign ("$") | |
374 | are not case hacked. There are times that this is undesirable, | |
375 | namely when you wish to link your program against a precompiled | |
376 | library which was compiled with a non-GNU-C compiler. X-windows (or | |
377 | DECWindows) is an example of this. In these instances, the | |
378 | /NOCASE_HACK switch should be used. | |
379 | ||
380 | If you require case hacking in some cases, but not in others (i.e. | |
381 | Libg++ with DECWindows), then it is recommended that you develop a | |
382 | header file which will define all mixed case functions that should | |
383 | not have a case hack as the lower case equivalents. | |
384 | ||
385 | GNU-C does not provide the globaldef and globalref mechanism | |
386 | which is used by VAX-C to coerce the VMS linker to include certain | |
387 | object modules from a library. There are assembler hacks, which are | |
388 | available to the user through the macros defined in gnu_hacks.h, | |
389 | which effectively give you the ability to perform these functions. | |
390 | While not syntactically identical, they do provide most of the | |
391 | functionality. | |
392 | ||
393 | Note that globaldefs of enums is not supported in the way that it is | |
394 | under VAX-C. This can be easily simulated, however, by globaldefing | |
395 | an integer variable, and then globalvaluing all of the enumerated | |
396 | states. | |
397 | ||
398 | Furthermore, the way that globalvalue is currently implemented, the | |
399 | data type of the globalvalue variable is seen to the compiler to be a | |
400 | pointer to the data type that you specify. This is necessary in | |
401 | order to make the compiler correctly address the globalvalue | |
402 | variables. | |
403 |