Steve Youngs <youngs(a)xemacs.org> wrote:
- I'm still having that problem with modules and building with
'--error-checking=all'...
M-x load-module RET
/usr/local/lib/xemacs-21.5-b9/i586-pc-linux/modules/postgresql.ell RET
=> Dll error: Cannot open dynamic module,
"/usr/local/lib/xemacs-21.5-b9/i586-pc-linux/modules/postgresql.ell"
(load-module "postgresql")
=> Dll error: Opening dynamic module,
"/usr/local/lib/xemacs-21.5-b9/i586-pc-linux/modules/postgresql.ell:
undefined symbol: error_check_pgconn"
I can finally reproduce this on my box, after watching the build process
on Steve's box. (Thanks, Steve!) Two elements must be present to
produce this behavior:
1) Configure with --error-checking=all
2) Compile with no optimization
This is taking place on Linux x86 boxes with gcc 2.95.3 in Steve's case,
and RedHat's so-called gcc 2.96 (RedHat 7.3) in my case.
This all arises from lrecord.h. The name error_check_pgconn is declared
in DECLARE_LRECORD, and used in XRECORD. In the case where the
misbehavior manifests itself, the preprocessed source (using the same
compiler flags used by the Makefile, except with -E replacing -c)
contains this before any use of error_check_pgconn (with white space
changes for clarity, coupled with removal of redundant parentheses and a
little constant folding):
extern const struct lrecord_implementation lrecord_pgconn;
inline extern Lisp_PGconn *
error_check_pgconn (Lisp_Object obj, const char *file, int line);
inline extern Lisp_PGconn *
error_check_pgconn (Lisp_Object obj, const char *file, int line) {
((enum Lisp_Type)((unsigned long)obj & ~((1UL << 30 - 1UL) << 2)) ==
Lisp_Type_Record &&
((struct lrecord_header *)obj)->type ==
(unsigned int)lrecord_type_pgconn)
? (void)0
: assert_failed(file, line,
"RECORD_TYPEP (obj, lrecord_type_pgconn)"));
return (Lisp_PGconn *)((void *)obj);
}
Doing "objdump -t postgresql.ell" on the offending postgresql.ell says
(in part):
postgresql.ell: file format elf32-i386
SYMBOL TABLE:
00000094 l d .hash 00000000
0000070c l d .dynsym 00000000
...
00000000 *UND* 00000000 error_check_pgconn
...
On the other hand, using *any* optimization makes the error_check_pgconn
entry disappear altogether; the inlining is complete. Furthermore, a
disassembly shows that error_check_pgconn is not called anywhere, so it
was compiled away even without optimization ... but an undefined entry
for it was inserted into the object file!
Can anyone with a gcc 3 handy see if this behavior persists?
Thanks,
--
Jerry James
http://www.ittc.ku.edu/~james/