|
2999
|
1 Contents: |
|
|
2 |
|
|
3 Reporting bugs |
|
|
4 Bug checklist |
|
|
5 Mailing lists |
|
|
6 Debugging |
|
|
7 Logging |
|
|
8 Common problems |
|
|
9 Unable to find files |
|
|
10 Slow path searching |
|
|
11 Unable to generate fonts |
|
|
12 TeX or Metafont failing |
|
3172
|
13 Empty Makefiles |
|
2999
|
14 `XtStrings' |
|
|
15 `dlopen' |
|
|
16 `ShellWidgetClass' |
|
|
17 Pointer combination warnings |
|
|
18 |
|
|
19 |
|
|
20 Reporting bugs |
|
|
21 ============== |
|
|
22 |
|
|
23 If you have problems or suggestions, please report them to |
|
|
24 <tex-k@mail.tug.org> using the bug checklist below. |
|
|
25 |
|
|
26 Please report bugs in the documentation; not only factual errors or |
|
|
27 inconsistent behavior, but unclear or incomplete explanations, typos, |
|
|
28 wrong fonts, ... |
|
|
29 |
|
|
30 Bug checklist |
|
|
31 ------------- |
|
|
32 |
|
|
33 Before reporting a bug, please check below to be sure it isn't already |
|
|
34 known (*note Common problems::.). |
|
|
35 |
|
|
36 Bug reports should be sent via electronic mail to |
|
|
37 <tex-k@mail.tug.org>, or by postal mail to 135 Center Hill Road / |
|
|
38 Plymouth, MA 02360 / USA. |
|
|
39 |
|
|
40 The general principle is that a good bug report includes all the |
|
|
41 information necessary for reproduction. Therefore, to enable |
|
|
42 investigation, your report should include the following: |
|
|
43 |
|
|
44 * The version number(s) of the program(s) involved, and of Kpathsea |
|
|
45 itself. You can get the former by giving a sole option `--version' |
|
|
46 to the program, and the latter by running `kpsewhich --version'. |
|
|
47 The `NEWS' and `ChangeLog' files also contain the version number. |
|
|
48 |
|
|
49 * The hardware, operating system (including version number), |
|
|
50 compiler, and `make' program you are using (the output of `uname |
|
|
51 -a' is a start on the first two, though often incomplete). If the |
|
|
52 bug involves the X window system, include X version and supplier |
|
|
53 information as well (examples: X11R6 from MIT; X11R4 from HP; |
|
|
54 OpenWindows 3.3 bundled with SunOS 4.1.4). |
|
|
55 |
|
|
56 * Any options you gave to `configure'. This is recorded in the |
|
|
57 `config.status' files. |
|
|
58 |
|
|
59 If you are reporting a bug in `configure' itself, it's probably |
|
|
60 system-dependent, and it will be unlikely the maintainers can do |
|
|
61 anything useful if you merely report that thus-and-such is broken. |
|
|
62 Therefore, you need to do some additional work: for some bugs, you |
|
|
63 can look in the file `config.log' where the test that failed should |
|
|
64 appear, along with the compiler invocation and source program in |
|
|
65 question. You can then compile it yourself by hand, and discover |
|
|
66 why the test failed. Other `configure' bugs do not involve the |
|
|
67 compiler; in that case, the only recourse is to inspect the |
|
|
68 `configure' shell script itself, or the Autoconf macros that |
|
|
69 generated `configure'. |
|
|
70 |
|
|
71 * The log of all debugging output, if the bug is in path searching. |
|
|
72 You can get this by setting the environment variable |
|
|
73 `KPATHSEA_DEBUG' to `-1' before running the program. Please look |
|
|
74 at the log yourself to make sure the behavior is really a bug |
|
|
75 before reporting it; perhaps "old" environment variable settings |
|
|
76 are causing files not to be found, for example. |
|
|
77 |
|
|
78 * The contents of any input files necessary to reproduce the bug. |
|
|
79 For bugs in DVI-reading programs, for example, this generally |
|
|
80 means a DVI file (and any EPS or other files it uses)--TeX source |
|
|
81 files are helpful, but the DVI file is necessary, because that's |
|
|
82 the actual program input. |
|
|
83 |
|
3285
|
84 GNU `shar', available from `ftp://ftp.gnu.org/pub/gnu/shar' is a |
|
2999
|
85 convenient way of packaging multiple (possibly binary) files for |
|
|
86 electronic mail. If you feel your input files are too big to send |
|
|
87 by email, you can ftp them to `ftp://ftp.tug.org/incoming' (that |
|
|
88 directory is writable, but not readable). |
|
|
89 |
|
|
90 * If you are sending a patch (do so if you can!), please do so in |
|
|
91 the form of a context diff (`diff -c') against the original |
|
|
92 distribution source. Any other form of diff is either not as |
|
|
93 complete or harder for me to understand. Please also include a |
|
|
94 `ChangeLog' entry. |
|
|
95 |
|
|
96 * If the bug involved is an actual crash (i.e., core dump), it is |
|
|
97 easy and useful to include a stack trace from a debugger (I |
|
|
98 recommend the GNU debugger GDB, available from |
|
3285
|
99 `ftp://ftp.gnu.org/pub/gnu/gdb'). If the cause is apparent (a |
|
2999
|
100 `NULL' value being dereferenced, for example), please send the |
|
|
101 details along. If the program involved is TeX or Metafont, and |
|
|
102 the crash is happening at apparently-sound code, however, the bug |
|
|
103 may well be in the compiler, rather than in the program or the |
|
|
104 library (*note TeX or Metafont failing: TeX or Metafont failing.). |
|
|
105 |
|
|
106 * Any additional information that will be helpful in reproducing, |
|
|
107 diagnosing, or fixing the bug. |
|
|
108 |
|
|
109 Mailing lists |
|
|
110 ------------- |
|
|
111 |
|
|
112 Web2c and Kpathsea in general are discussed on the mailing list |
|
|
113 <tex-k@mail.tug.org>. To join, email <tex-k-request@mail.tug.org> with |
|
|
114 a line consisting of |
|
|
115 |
|
|
116 subscribe YOU@YOUR.PREFERRED.EMAIL.ADDRESS |
|
|
117 |
|
|
118 in the body of the message. |
|
|
119 |
|
|
120 You do not need to join to submit a report, nor will it affect whether |
|
|
121 you get a response. There is no Usenet newsgroup equivalent (if you can |
|
|
122 be the one to set this up, email `tex-k-request'). Traffic on the list |
|
|
123 is fairly light, and is mainly bug reports and enhancement requests to |
|
|
124 the software. The best way to decide if you want to join or not is |
|
|
125 read some of the archives from `ftp://ftp.tug.org/mail/archives/tex-k/'. |
|
|
126 |
|
|
127 Be aware that large data files are sometimes included in bug reports. |
|
|
128 If this is a problem for you, do not join the list. |
|
|
129 |
|
|
130 If you only want announcements of new releases, not bug reports and |
|
|
131 discussion, join <tex-archive@math.utah.edu> (via mail to |
|
|
132 <tex-archive-request@math.utah.edu>). |
|
|
133 |
|
|
134 If you are looking for general TeX help, such as how to use LaTeX, |
|
|
135 please use the mailing list <info-tex@shsu.edu> mailing list, which is |
|
|
136 gatewayed to the `comp.text.tex' Usenet newsgroup (or post to the |
|
|
137 newsgroup; the gateway is bidirectional). |
|
|
138 |
|
|
139 Debugging |
|
|
140 --------- |
|
|
141 |
|
|
142 Kpathsea provides a number of runtime debugging options, detailed |
|
|
143 below by their names and corresponding numeric values. When the files |
|
|
144 you expect aren't being found, the thing to do is enable these options |
|
|
145 and examine the output. |
|
|
146 |
|
|
147 You can set these with some runtime argument (e.g., `-d') to the |
|
|
148 program; in that case, you should use the numeric values described in |
|
|
149 the program's documentation (which, for Dvipsk and Xdvik, are different |
|
|
150 than those below). It's best to give the `-d' (or whatever) option |
|
|
151 first, for maximal output. Dvipsk and Xdvik have additional |
|
|
152 program-specific debugging options as well. |
|
|
153 |
|
|
154 You can also set the environment variable `KPATHSEA_DEBUG'; in this |
|
3172
|
155 case, you should use the numbers below. If you run the program under a |
|
|
156 debugger and set the variable `kpathsea_debug', also use the numbers |
|
|
157 below. |
|
2999
|
158 |
|
|
159 In any case, by far the simplest value to use is `-1', which will |
|
|
160 turn on all debugging output. This is usually better than guessing |
|
|
161 which particular values will yield the output you need. |
|
|
162 |
|
|
163 Debugging output always goes to standard error, so you can redirect it |
|
|
164 easily. For example, in Bourne-compatible shells: |
|
|
165 dvips -d -1 ... 2>/tmp/debug |
|
|
166 |
|
|
167 It is sometimes helpful to run the standalone Kpsewhich utility |
|
|
168 (*note Invoking kpsewhich::.), instead of the original program. |
|
|
169 |
|
|
170 In any case, you can *not* use the *names* below; you must always use |
|
|
171 somebody's numbers. (Sorry.) To set more than one option, just sum |
|
|
172 the corresponding numbers. |
|
|
173 |
|
|
174 `KPSE_DEBUG_STAT (1)' |
|
|
175 Report `stat'(2) calls. This is useful for verifying that your |
|
|
176 directory structure is not forcing Kpathsea to do many additional |
|
|
177 file tests (*note Slow path searching::., and *note Subdirectory |
|
|
178 expansion::.). If you are using an up-to-date `ls-R' database |
|
|
179 (*note Filename database::.), this should produce no output unless |
|
|
180 a nonexistent file that must exist is searched for. |
|
|
181 |
|
|
182 `KPSE_DEBUG_HASH (2)' |
|
|
183 Report lookups in all hash tables: `ls-R' and `aliases' (*note |
|
|
184 Filename database::.); font aliases (*note Fontmap::.); and config |
|
|
185 file values (*note Config files::.). Useful when expected values |
|
|
186 are not being found, e.g.., file searches are looking at the disk |
|
|
187 instead of using `ls-R'. |
|
|
188 |
|
|
189 `KPSE_DEBUG_FOPEN (4)' |
|
|
190 Report file openings and closings. Especially useful when your |
|
|
191 system's file table is full, for seeing which files have been |
|
|
192 opened but never closed. In case you want to set breakpoints in a |
|
|
193 debugger: this works by redefining `fopen' (`fclose') to be |
|
|
194 `kpse_fopen_trace' (`kpse_fclose_trace'). |
|
|
195 |
|
|
196 `KPSE_DEBUG_PATHS (8)' |
|
|
197 Report general path information for each file type Kpathsea is |
|
|
198 asked to search. This is useful when you are trying to track down |
|
|
199 how a particular path got defined--from `texmf.cnf', `config.ps', |
|
|
200 an environment variable, the compile-time default, etc. This is |
|
|
201 the contents of the `kpse_format_info_type' structure defined in |
|
|
202 `tex-file.h'. |
|
|
203 |
|
|
204 `KPSE_DEBUG_EXPAND (16)' |
|
|
205 Report the directory list corresponding to each path element |
|
|
206 Kpathsea searches. This is only relevant when Kpathsea searches |
|
|
207 the disk, since `ls-R' searches don't look through directory lists |
|
|
208 in this way. |
|
|
209 |
|
|
210 `KPSE_DEBUG_SEARCH (32)' |
|
|
211 Report on each file search: the name of the file searched for, the |
|
|
212 path searched in, whether or not the file must exist (when drivers |
|
|
213 search for `cmr10.vf', it need not exist), and whether or not we |
|
|
214 are collecting all occurrences of the file in the path (as with, |
|
|
215 e.g., `texmf.cnf' and `texfonts.map'), or just the first (as with |
|
|
216 most lookups). This can help you correlate what Kpathsea is doing |
|
|
217 with what is in your input file. |
|
|
218 |
|
3172
|
219 `KPSE_DEBUG_VARS (64)' |
|
|
220 Report the value of each variable Kpathsea looks up. This is |
|
|
221 useful for verifying that variables do indeed obtain their correct |
|
|
222 values. |
|
|
223 |
|
|
224 `GSFTOPK_DEBUG (128)' |
|
|
225 Activates debugging printout specific to `gsftopk' program. |
|
|
226 |
|
|
227 `MAKETEX_DEBUG (512)' |
|
|
228 If you use the optional `mktex' programs instead of the |
|
|
229 traditional shell scripts, this will report the name of the site |
|
|
230 file (`mktex.cnf' by default) which is read, directories created by |
|
|
231 `mktexdir', the full path of the `ls-R' database built by |
|
|
232 `mktexlsr', font map searches, `MT_FEATURES' in effect, parameters |
|
|
233 from `mktexnam', filenames added by `mktexupd', and some |
|
|
234 subsidiary commands run by the programs. |
|
|
235 |
|
|
236 `MAKETEX_FINE_DEBUG (1024)' |
|
|
237 When the optional `mktex' programs are used, this will print |
|
|
238 additional debugging info from functions internal to these |
|
|
239 programs. |
|
|
240 |
|
2999
|
241 Debugging output from Kpathsea is always written to standard error, |
|
|
242 and begins with the string `kdebug:'. (Except for hash table buckets, |
|
|
243 which just start with the number, but you can only get that output |
|
|
244 running under a debugger. See comments at the `hash_summary_only' |
|
|
245 variable in `kpathsea/db.c'.) |
|
|
246 |
|
|
247 Logging |
|
|
248 ------- |
|
|
249 |
|
|
250 Kpathsea can record the time and filename found for each successful |
|
|
251 search. This may be useful in finding good candidates for deletion when |
|
|
252 your filesystem is full, or in discovering usage patterns at your site. |
|
|
253 |
|
|
254 To do this, define the environment or config file variable |
|
|
255 `TEXMFLOG'. The value is the name of the file to append the |
|
|
256 information to. The file is created if it doesn't exist, and appended |
|
|
257 to if it does. |
|
|
258 |
|
|
259 Each successful search turns into one line in the log file: two words |
|
|
260 separated by a space. The first word is the time of the search, as the |
|
|
261 integer number of seconds since "the epoch", i.e., UTC midnight 1 |
|
|
262 January 1970 (more precisely, the result of the `time' system call). |
|
|
263 The second word is the filename. |
|
|
264 |
|
|
265 For example, after `setenv TEXMFLOG /tmp/log', running Dvips on |
|
|
266 `story.dvi' appends the following lines: |
|
|
267 |
|
|
268 774455887 /usr/local/share/texmf/dvips/config.ps |
|
|
269 774455887 /usr/local/share/texmf/dvips/psfonts.map |
|
|
270 774455888 /usr/local/share/texmf/dvips/texc.pro |
|
|
271 774455888 /usr/local/share/texmf/fonts/pk/ljfour/public/cm/cmbx10.600pk |
|
|
272 774455889 /usr/local/share/texmf/fonts/pk/ljfour/public/cm/cmsl10.600pk |
|
|
273 774455889 /usr/local/share/texmf/fonts/pk/ljfour/public/cm/cmr10.600pk |
|
|
274 774455889 /usr/local/share/texmf/dvips/texc.pro |
|
|
275 |
|
|
276 Only filenames that are absolute are recorded, to preserve some |
|
|
277 semblance of privacy. |
|
|
278 |
|
|
279 Common problems |
|
|
280 --------------- |
|
|
281 |
|
|
282 Here are some common problems with configuration, compilation, |
|
|
283 linking, execution, ... |
|
|
284 |
|
|
285 Unable to find files |
|
|
286 .................... |
|
|
287 |
|
|
288 If a program complains it cannot find fonts (or other input files), |
|
|
289 any of several things might be wrong. In any case, you may find the |
|
|
290 debugging options helpful. *Note Debugging::. |
|
|
291 |
|
|
292 * Perhaps you simply haven't installed all the necessary files; the |
|
|
293 basic fonts and input files are distributed separately from the |
|
|
294 programs. *Note unixtex.ftp::. |
|
|
295 |
|
|
296 * You have (perhaps unknowingly) told Kpathsea to use search paths |
|
|
297 that don't reflect where the files actually are. One common cause |
|
|
298 is having environment variables set from a previous installation, |
|
|
299 thus overriding what you carefully set in `texmf.cnf' (*note |
|
|
300 Supported file formats::.). System `/etc/profile' or other files |
|
|
301 such may be the culprit. |
|
|
302 |
|
|
303 * Your files reside in a directory that is only pointed to via a |
|
|
304 symbolic link, in a leaf directory and is not listed in `ls-R'. |
|
|
305 |
|
|
306 Unfortunately, Kpathsea's subdirectory searching has an |
|
|
307 irremediable deficiency: If a directory D being searched for |
|
|
308 subdirectories contains plain files and symbolic links to other |
|
|
309 directories, but no true subdirectories, D will be considered a |
|
|
310 leaf directory, i.e., the symbolic links will not be followed. |
|
|
311 *Note Subdirectory expansion::. |
|
|
312 |
|
|
313 You can work around this problem by creating an empty dummy |
|
|
314 subdirectory in D. Then D will no longer be a leaf, and the |
|
|
315 symlinks will be followed. |
|
|
316 |
|
|
317 The directory immediately followed by the `//' in the path |
|
|
318 specification, however, is always searched for subdirectories, |
|
|
319 even if it is a leaf. Presumably you would not have asked for the |
|
|
320 directory to be searched for subdirectories if you didn't want it |
|
|
321 to be. |
|
|
322 |
|
3172
|
323 * If the fonts (or whatever) don't already exist, `mktexpk' (or |
|
|
324 `mktexmf' or `mktextfm') will try to create them. If these rather |
|
|
325 complicated shell scripts fail, you'll eventually get an error |
|
|
326 message saying something like `Can't find font FONTNAME'. The best |
|
|
327 solution is to fix (or at least report) the bug in `mktexpk'; the |
|
|
328 workaround is to generate the necessary fonts by hand with |
|
|
329 Metafont, or to grab them from a CTAN site (*note unixtex.ftp::.). |
|
2999
|
330 |
|
|
331 * There is a bug in the library. *Note Reporting bugs::. |
|
|
332 |
|
|
333 Slow path searching |
|
|
334 ................... |
|
|
335 |
|
|
336 If your program takes an excessively long time to find fonts or other |
|
|
337 input files, but does eventually succeed, here are some possible |
|
|
338 culprits: |
|
|
339 |
|
|
340 * Most likely, you just have a lot of directories to search, and that |
|
|
341 takes a noticeable time. The solution is to create and maintain a |
|
|
342 separate `ls-R' file that lists all the files in your main TeX |
|
|
343 hierarchy. *Note Filename database::. Kpathsea always uses `ls-R' |
|
|
344 if it's present; there's no need to recompile or reconfigure any |
|
|
345 of the programs. |
|
|
346 |
|
|
347 * Your recursively-searched directories (e.g., |
|
|
348 `/usr/local/share/texmf/fonts//'), contain a mixture of files and |
|
|
349 directories. This prevents Kpathsea from using a useful |
|
|
350 optimization (*note Subdirectory expansion::.). |
|
|
351 |
|
|
352 It is best to have only directories (and perhaps a `README') in the |
|
|
353 upper levels of the directory structure, and it's very important |
|
|
354 to have *only* files, and no subdirectories, in the leaf |
|
|
355 directories where the dozens of TFM, PK, or whatever files reside. |
|
|
356 |
|
|
357 In any case, you may find the debugging options helpful in determining |
|
|
358 precisely when the disk or network is being pounded. *Note Debugging::. |
|
|
359 |
|
|
360 Unable to generate fonts |
|
|
361 ........................ |
|
|
362 |
|
3172
|
363 This can happen if either `mktexpk' hasn't been installed properly, |
|
2999
|
364 or if the local installation of Metafont isn't correct. |
|
|
365 |
|
3172
|
366 If `mf' is a command not found by `mktexpk', then you need to install |
|
|
367 Metafont (*note unixtex.ftp::.). |
|
2999
|
368 |
|
|
369 If Metafont runs, but generates fonts at the wrong resolution, you |
|
|
370 need to be sure the `M' and `D' lines in your Dvips configuration file |
|
|
371 match (*note Config files: (dvips)Config files.). For example, if |
|
3172
|
372 `mktexpk' is generating 300dpi fonts, but you need 600dpi fonts, you |
|
2999
|
373 should have: |
|
|
374 M ljfour |
|
|
375 D 600 |
|
|
376 |
|
|
377 If Metafont runs but generates fonts at a resolution of 2602dpi (and |
|
|
378 prints out the name of each character as well as just a character |
|
|
379 number, and maybe tries to display the characters), then your Metafont |
|
|
380 base file probably hasn't been made properly. (It's using the default |
|
|
381 `proof' mode, instead of an actual device mode.) To make a proper |
|
|
382 `plain.base', assuming the local mode definitions are contained in a |
|
|
383 file `modes.mf', run the following command (assuming Unix): |
|
|
384 |
|
|
385 inimf "plain; input modes; dump" |
|
|
386 |
|
|
387 Then copy the `plain.base' file from the current directory to where the |
|
|
388 base files are stored on your system (`/usr/local/share/texmf/web2c' by |
|
|
389 default), and make a link (either hard or soft) from `plain.base' to |
|
|
390 `mf.base' in that directory. *Note inimf invocation: (web2c)inimf |
|
|
391 invocation. |
|
|
392 |
|
|
393 TeX or Metafont failing |
|
|
394 ....................... |
|
|
395 |
|
|
396 If TeX or Metafont get a segmentation fault or otherwise fail while |
|
|
397 running a normal input file, the problem is usually a compiler bug |
|
|
398 (unlikely as that may sound). Even if the trip and trap tests are |
|
|
399 passed, problems may lurk. Optimization occasionally causes trouble in |
|
|
400 programs other than TeX and Metafont themselves, too. |
|
|
401 |
|
|
402 Insufficient swap space may also cause core dumps or other erratic |
|
|
403 behavior. |
|
|
404 |
|
|
405 For a workaround, if you enabled any optimization flags, it's best to |
|
|
406 omit optimization entirely. In any case, the way to find the facts is |
|
|
407 to run the program under the debugger and see where it's failing. |
|
|
408 |
|
|
409 Also, if you have trouble with a system C compiler, I advise trying |
|
|
410 the GNU C compiler. And vice versa, unfortunately; but in that case I |
|
3172
|
411 also recommend reporting a bug to the GCC mailing list; see *Note Bugs: |
|
|
412 (gcc)Bugs. |
|
2999
|
413 |
|
|
414 To report compiler bugs effectively requires perseverance and |
|
|
415 perspicacity: you must find the miscompiled line, and that usually |
|
|
416 involves delving backwards in time from the point of error, checking |
|
|
417 through TeX's (or whatever program's) data structures. Things are not |
|
|
418 helped by all-too-common bugs in the debugger itself. Good luck. |
|
|
419 |
|
3172
|
420 One known cause of trouble is the way arrays are handled. Some of the |
|
|
421 Pascal arrays have a lower index other than 0, and the C code will take |
|
|
422 the pointer to the allocated memory, subtract the lower index, and use |
|
|
423 the resulting pointer for the array. While this trick often works, ANSI |
|
|
424 C doesn't guarantee that it will. It it known to fail on HP-UX 10 |
|
|
425 mchines when the native compiler is used, unless the `+u' compiler |
|
|
426 switch was specified. Using GCC will work on this platform as well. |
|
|
427 |
|
|
428 Empty Makefiles |
|
|
429 ............... |
|
|
430 |
|
|
431 On some systems (NetBSD, FreeBSD, AIX 4.1, and Mach10), `configure' |
|
|
432 may fail to properly create the Makefiles. Instead, you get an error |
|
|
433 which looks something like this: |
|
|
434 |
|
|
435 prompt$ ./configure |
|
|
436 ... |
|
|
437 creating Makefile |
|
|
438 sed: 1: "\\@^ac_include make/pat ...": \ can not be used as a string delimiter |
|
|
439 |
|
|
440 So far as I know, the bug here is in `/bin/sh' on these systems. I |
|
|
441 don't have access to a machine running any of them, so if someone can |
|
|
442 find a workaround that avoids the quoting bug, I'd be most grateful. |
|
|
443 (Search for `ac_include' in the `configure' script to get to the |
|
|
444 problematic code.) |
|
|
445 |
|
|
446 It should work to run `bash configure', instead of using `/bin/sh'. |
|
3285
|
447 You can get Bash from `ftp://ftp.gnu.org/pub/gnu/bash' and mirrors. |
|
3172
|
448 |
|
|
449 Another possible cause (reported for NeXT) is a bug in the `sed' |
|
|
450 command. In that case the error may look like this: |
|
|
451 |
|
|
452 Unrecognized command: \@^ac_include make/paths.make@r make/paths.make |
|
|
453 |
|
|
454 In this case, installing GNU `sed' should solve the problem. You can |
|
|
455 get GNU `sed' from the same places as Bash. |
|
|
456 |
|
2999
|
457 `XtStrings' |
|
|
458 ........... |
|
|
459 |
|
|
460 You may find that linking X programs results in an error from the |
|
|
461 linker that `XtStrings' is undefined, something like this: |
|
|
462 |
|
|
463 gcc -o virmf ... |
|
|
464 .../x11.c:130: undefined reference to `XtStrings' |
|
|
465 |
|
|
466 This generally happens because of a mismatch between the X include |
|
|
467 files with which you compiled and the X libraries with which you linked; |
|
|
468 often, the include files are from MIT and the libraries from Sun. |
|
|
469 |
|
|
470 The solution is to use the same X distribution for compilation and |
|
|
471 linking. Probably `configure' was unable to guess the proper |
|
|
472 directories from your installation. You can use the `configure' |
|
|
473 options `--x-includes=PATH' and `--x-libraries=PATH' to explicitly |
|
|
474 specify them. |
|
|
475 |
|
|
476 `dlopen' |
|
|
477 ........ |
|
|
478 |
|
|
479 (This section adapted from the file `dlsym.c' in the X distribution.) |
|
|
480 |
|
|
481 The `Xlib' library uses the standard C function `wcstombs'. Under |
|
|
482 SunOS 4.1, `wcstombs' uses the `dlsym' interface defined in `libdl.so'. |
|
|
483 Unfortunately, the SunOS 4.1 distribution does not include a static |
|
|
484 `libdl.a' library. |
|
|
485 |
|
|
486 As a result, if you try to link an X program statically under SunOS, |
|
|
487 you may get undefined references to `dlopen', `dlsym', and `dlclose'. |
|
|
488 One workaround is to include these definitions when you link: |
|
|
489 |
|
|
490 void *dlopen() { return 0; } |
|
|
491 void *dlsym() { return 0; } |
|
|
492 int dlclose() { return -1; } |
|
|
493 |
|
|
494 These are contained in the `dlsym.c' file in the MIT X distribution. |
|
|
495 |
|
|
496 `ShellWidgetClass' |
|
|
497 .................. |
|
|
498 |
|
|
499 (This section adapted from the comp.sys.sun.admin FAQ.) |
|
|
500 |
|
|
501 If you are linking with Sun's OpenWindows libraries in SunOS 4.1.x, |
|
|
502 you may get undefined symbols `_get_wmShellWidgetClass' and |
|
|
503 `_get_applicationShellWidgetClass' when linking. This problem does not |
|
|
504 arise using the standard MIT X libraries under SunOS. |
|
|
505 |
|
|
506 The cause is bugs in the `Xmu' shared library as shipped from Sun. |
|
|
507 There are several fixes: |
|
|
508 |
|
|
509 * Install the free MIT distribution from `ftp.x.org' and mirrors. |
|
|
510 |
|
|
511 * Get the OpenWindows patches listed below. |
|
|
512 |
|
|
513 * Statically link the `Xmu' library into the executable. |
|
|
514 |
|
3172
|
515 * Avoid using `Xmu' at all. If you are compiling Metafont, see *Note |
|
|
516 Online Metafont graphics: (web2c)Online Metafont graphics. If you |
|
2999
|
517 are compiling Xdvi, see the `-DNOTOOL' option in `xdvik/INSTALL'. |
|
|
518 |
|
|
519 * Ignore the errors. The binary runs fine regardless. |
|
|
520 |
|
|
521 Here is the information for getting the two patches: |
|
|
522 |
|
|
523 Patch ID: 100512-02 |
|
|
524 Bug ID's: 1086793, 1086912, 1074766 |
|
|
525 Description: 4.1.x OpenWindows 3.0 `libXt' jumbo patch |
|
|
526 |
|
|
527 Patch ID: 100573-03 |
|
|
528 Bug ID: 1087332 |
|
|
529 Description: 4.1.x OpenWindows 3.0 undefined symbols when using shared `libXmu'. |
|
|
530 |
|
|
531 The way to statically link with `libXmu' depends on whether you are |
|
|
532 using a Sun compiler (e.g., `cc') or `gcc'. If the latter, alter the |
|
|
533 `x_libs' Make variable to include |
|
|
534 |
|
|
535 -static -lXmu -dynamic |
|
|
536 |
|
|
537 If you are using the Sun compiler, use `-Bstatic' and `-Bdynamic'. |
|
|
538 |
|
|
539 Pointer combination warnings |
|
|
540 ............................ |
|
|
541 |
|
|
542 When compiling with old C compilers, you may get some warnings about |
|
|
543 "illegal pointer combinations". These are spurious; just ignore them. |
|
|
544 I decline to clutter up the source with casts to get rid of them. |
|
|
545 |
