Steve Youngs <youngs(a)xemacs.org&gt; wrote: Yes, I've been aware of this for awhile. I've been pondering how to fix it properly. I'm wondering if maybe the autoload forms for a given module should be wrapped in something like (when (file-exists-p "module.ell") (autoload ...) ... ) That way the autoloads depend only on the sources, not on a particular configuration. On the other hand, this doesn't support installing new modules later on that did not exist when the XEmacs binary was compiled. On the gripping hand, that would still be a problem if auto-autoloads.el contained only autoloads for modules installed at build time. Urk! That apparently means that ERROR_CHECK_TYPES was not defined during compilation of the module code, but was for the main sources (see lrecord.h). But how is that possible? That symbol is defined in config.h, which is included first thing by postgresql.c! I don't get it... Only if I understand the problem and have an actual solution. :-) -- Jerry James http://www.ittc.ku.edu/~james/

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; wrote: [snip] Right. So, as you say below, what we really want are required modules, which are distributed with the core (or maybe as part of xemacs-base or something like it) and use code like your above, and optional modules that are distributed as packages with self-contained autoloads. Hmmmm. Mind if *I* worry? I have been thinking about this idly now and then. Maybe I'll think about it seriously while on an extended trip at the end of this month.... -- Jerry James, who has lost every chess game he's ever played http://www.ittc.ku.edu/~james/

SY> I really disagree quite strongly here. IMO, the autoloads SY> should only be built for modules that are installed. Jerry's SY> solution of wrapping them in a '(when (file-exists-p SY> "module.ell"))' does the next best thing and works well. If the module is in a package, auto-autoloads will only be built when it is installed. If it is part of core, then an XEmacs that doesn't have it is known to be crippled and it should do something more informative than barf on an undefined function---it should present an informed guess as to why the function is undefined. This is one reason why Ben wants xemacs-base back in core, for example. SJT> The fact that today's sources include clearly optional stuff SJT> like postgresql and ldap should be considered transitional SY> Why? The core is full of optional stuff that isn't considered SY> transitional. I don't think I quite understand what you're SY> getting at, Stephen. If it's optional, we should show it the door to packages. I want to get as much stuff out of core as possible. For two reasons. First, it improves response time to patches if the modules are in packages. Second, the less stuff there is in core, the more stable it can be. SY> Yeah but it wouldn't take too much time and effort for some SY> smart cookie to come up with a way for autoload.el to overcome SY> this. :-) Oh yeah? autoload.el is full of "WTF??!?" comments. As Jerry knows, I think he put a couple of them in there. :-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

|--==> "JJ" == Jerry James <james(a)eecs.ku.edu&gt; writes: JJ> Steve Youngs <youngs(a)xemacs.org&gt; wrote: JJ> Steve, do you see this with a fresh compile? I can't reproduce JJ> it. (pq-connectdb "dbname=users_db") => Dll error: Opening dynamic module, "/usr/local/lib/xemacs-21.5-b9/i686-pc-linux/modules/postgresql.ell: undefined symbol: error_check_pgconn" Backtrace: # bind (standard-output stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error) # (unwind-protect ...) # (unwind-protect ...) load-module("postgresql") # bind (load-modules-quietly path handler filename nosuffix nomessage noerror file) load("postgresql" nil nil nil) # (unwind-protect ...) (pq-connectdb "dbname=users_db") eval((pq-connectdb "dbname=users_db")) # bind (expr) eval-interactive((pq-connectdb "dbname=users_db")) # bind (standard-output opoint ignore-quotes eval-last-sexp-arg-internal) eval-last-sexp(t) # bind (standard-output) #<compiled-function nil "...(13)" [standard-output terpri eval-last-sexp t] 2 1090158 nil>() call-interactively(eval-print-last-sexp) # (condition-case ... . error) # (catch top-level ...) Doing a simple 'M-x load-module RET /path/to/postgresql.ell RET' gives me: Dll error: Cannot open dynamic module, "/usr/local/lib/xemacs-21.5-b9/i686-pc-linux/modules/postgresql.ell" Backtrace: # bind (standard-output stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error) # (unwind-protect ...) # (unwind-protect ...) load-module("/usr/local/lib/xemacs-21.5-b9/i686-pc-linux/modules/postgresql.ell") # bind (command-debug-status) call-interactively(load-module) command-execute(load-module t) # bind (_execute_command_keys_ _execute_command_name_ prefix-arg) execute-extended-command(nil) # bind (command-debug-status) call-interactively(execute-extended-command) # (condition-case ... . error) # (catch top-level ...) Am I doing something wrong? -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "JJ" == Jerry James <james(a)xemacs.org&gt; writes: JJ> Steve Youngs <youngs(a)xemacs.org&gt; wrote: JJ> I don't know. It's still weird that the binary has error JJ> checking on and the modules don't. What's weirder is that I JJ> am also working on an i686-pc-linux machine, and I'm not JJ> seeing this. Can you give me the exact set of configure JJ> flags you used, and maybe say something about your Linux JJ> setup, too? Do you want anything that 'describe-installation' doesn't give? "say something about my Linux setup" is a bit general. :-) Um, lesse, it's pretty much a Slackware system, 2.4.19 kernel, glibc 2.2.5, gcc 3.3. My PostgreSQL is rooted at /usr/local/pgsql/, version 7.1.3. uname -a: Linux eicq 2.4.19 #1 Sun Aug 4 13:24:52 EST 2002 i686 unknown ./configure '--extra-verbose' '--dynamic=yes' '--with-gtk=no' '--with-gnome=no' '--with-toolbars=yes' '--with-wmcommand=yes' '--with-athena=next' '--with-menubars=lucid' '--with-scrollbars=athena' '--with-dialogs=athena' '--with-widgets=athena' '--with-sound=native,noesd' '--with-modules' '--with-site-modules=yes' '--with-site-lisp=no' '--pdump' '--with-mule' '--debug' '--memory-usage-stats' '--error-checking=all' '--use-union-type' '--with-clash-detection' '--site-libraries=/usr/local/pgsql/lib' XEmacs 21.5-b9 "brussels sprouts" (+CVS-20021012) configured for `i686-pc-linux'. Compilation / Installation: Source code location: /usr/local/src/xemacs Installation prefix: /usr/local Additional libraries: /usr/local/pgsql/lib Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -ggdb3 -Wall -Wchar-subscripts -Wunused -Wundef -Wshadow -Wsign-compare -Wmissing-declarations -Wunreachable-code -march=athlon Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/neXtaw - Athena library to link: neXtaw Using Lucid menubars. Using Athena scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Databases: Compiling in support for Berkeley database. Compiling in support for GNU DBM. Compiling in support for PostgreSQL. - Using PostgreSQL header file: pgsql/libpq-fe.h - Using PostgreSQL V7 bindings. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for dynamic shared object modules. Using the union type for Lisp_Objects. Using the new portable dumper. Compiling in support for extra debugging code. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

SY> Do you want anything that 'describe-installation' doesn't SY> give? sjt> Do you have an installed 21.5? If so, poke around and see if sjt> there's an old config.h in there somewhere, say in sjt> $archlibdir/include/config.h. OK, that turns out not to be a problem; the build log shows that ellcc does not look in the installed hierarchy. However, I did find another anomoly: "make beta" does not build the modules! I don't understand how you could get the conflict you're seeing from that, though, because make beta does _clean_ the modules. So you shouldn't have a module there to have the wrong value of error-checking. Weird.... I'm not sure what the right fix for the missing dependency in the beta target is. I'm adding ${PROGNAME} as a dependency to the beta target, but it seems like it was deliberately left out. If you do that, then beta: clean all seems equivalent. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: SY> Do you want anything that 'describe-installation' doesn't SY> give? SJT> Do you have an installed 21.5? If so, poke around and see SJT> if there's an old config.h in there somewhere, say in SJT> $archlibdir/include/config.h. Nope. Part of my testing included building a fresh XEmacs *after* removing the installed version. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "JJ" == Jerry James <james(a)xemacs.org&gt; writes: JJ> I configured with your options (except that I don't have the JJ> NeXT widgets, and I have gcc 2.96 and PostgreSQL 7.2.1, but none JJ> of that should matter), built, and installed. It worked for me. Bugger! JJ> Would you please check the value of module-load-path in your JJ> XEmacs, and then check each directory in that path to see if you JJ> have old versions of the modules lying around? Also, note that JJ> my last patch fixed a bug in the setting of module-load-path, so JJ> doing a cvs up and trying again might help. (symbol-value 'module-load-path) => ("/usr/local/lib/xemacs-21.5-b9/i686-pc-linux/modules/" "/usr/local/lib/xemacs/site-modules/") ,----[ ls on those 2 directories ] | /usr/local/lib/xemacs-21.5-b9/i686-pc-linux/modules: | auto-autoloads.el | auto-autoloads.elc | postgresql.ell | | /usr/local/lib/xemacs/site-modules: `---- No, cvs up didn't help. :-( -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "JJ" == Jerry James <james(a)xemacs.org&gt; writes: JJ> Since error-checking is determined by config.h defines, can JJ> you please insert this code somewhere after the includes in JJ> postgresql.c and see if it compiles successfully? JJ> #ifndef _SRC_CONFIG_H_ JJ> #error _SRC_CONFIG_H not defined JJ> #endif I slotted it in here... #include "process.h" /* Are the error checking symbols coming through? */ #ifndef _SRC_CONFIG_H_ #error _SRC_CONFIG_H not defined #endif #ifdef RUNNING_XEMACS_21_1 /* handle interface changes */ Compiling it... cd ./modules/postgresql && gmake all gmake[1]: Entering directory `/usr/local/src/xemacs/modules/postgresql' ../../lib-src/ellcc -ggdb3 -Wall -Wchar-subscripts -Wunused -Wundef -Wshadow -Wsign-compare -Wmissing-declarations -Wunreachable-code -march=athlon --mode=compile --mod-output=postgresql.o -I../../src -I/usr/local/src/xemacs/modules/postgresql/../../src -c postgresql.c postgresql.c: In function `Fpq_connectdb': postgresql.c:511: warning: will never be executed postgresql.c: In function `Fpq_connect_start': postgresql.c:557: warning: will never be executed postgresql.c: In function `Fpq_notifies': postgresql.c:1394: warning: will never be executed postgresql.c: At top level: postgresql.c:1889: warning: no previous declaration for `unload_postgresql' ELLMAKEDOC=../../lib-src/make-docfile ../../lib-src/ellcc --mode=init --mod-output=postgresql_i.c \ --mod-name=postgresql --mod-version=1.0.0 \ --mod-title="PostgreSQL Client Interface for XEmacs" /usr/local/src/xemacs/modules/postgresql/postgresql.c ../../lib-src/ellcc -ggdb3 -Wall -Wchar-subscripts -Wunused -Wundef -Wshadow -Wsign-compare -Wmissing-declarations -Wunreachable-code -march=athlon --mode=compile --mod-output=postgresql_i.o -I../../src -I/usr/local/src/xemacs/modules/postgresql/../../src -c postgresql_i.c In file included from postgresql_i.c:3: ../../src/emodules.h:92:1: warning: "staticpro" redefined In file included from ../../src/emodules.h:37, from postgresql_i.c:3: ../../src/lisp.h:3244:1: warning: this is the location of the previous definition postgresql_i.c:12: warning: no previous declaration for `docs_of_postgresql' ../../lib-src/ellcc --mode=link --mod-output=postgresql.ell postgresql.o postgresql_i.o -L/usr/local/pgsql/lib -L/usr/X11R6/lib -lpq gmake[1]: Leaving directory `/usr/local/src/xemacs/modules/postgresql' Trying to load it... (load-module "postgresql") => Dll error: Opening dynamic module, "/usr/local/lib/xemacs-21.5-b9/i686-pc-linux/modules/postgresql.ell: undefined symbol: error_check_pgconn" # bind (standard-output stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error) # (unwind-protect ...) # (unwind-protect ...) load-module("postgresql") eval((load-module "postgresql")) # bind (expr) eval-interactive((load-module "postgresql")) # bind (standard-output opoint ignore-quotes eval-last-sexp-arg-internal) eval-last-sexp(t) # bind (standard-output) #<compiled-function nil "...(13)" [standard-output terpri eval-last-sexp t] 2 1090158 nil>() call-interactively(eval-print-last-sexp) # (condition-case ... . error) # (catch top-level ...) -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "JJ" == Jerry James <james(a)xemacs.org&gt; writes: JJ> And here is another clue. You shouldn't be getting these JJ> warnings. Let's figure out why you are. There is a JJ> configure.ac in the modules/postgresql directory. Has that been JJ> instantiated? That is, is there a configure script in that JJ> directory? If so, has it been run (e.g., is there a config.log JJ> there)? Ah! That's gotta be the problem. Two questions: Why is there a configure.ac in there in the first place? And why is it 'AC_PREREQ(2.53)'? The reasons I asked those two questions are: a) There are a _lot_ of subdirectories in core and the _only_ place apart from toplevel that any configure scripts are is in the modules... ,----[ find ./ -regex "^.*configure\.\(ac\|in\)$" ] | ./configure.in | ./modules/ldap/configure.ac | ./modules/sample/external/configure.ac | ./modules/sample/internal/configure.ac | ./modules/postgresql/configure.ac | ./configure.ac `---- b) XEmacs' autoconf requirement is 2.13, we've got too much home grown magic voodoo chicken spells in our configure that give autoconf 2.5x bad indigestion... ,----[ ./configure.ac ] | AC_FATAL([ | | #### Autoconf 2.5x is not yet supported by XEmacs. | #### Our configure script is known *not* to work with these versions of | #### Autoconf. Please continue using Autoconf 2.13 for now. | ]) `---- I think the modules should be configured from the toplevel configure script, no? Feel free to shoot me down in flames if you think I'm wrong. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "JJ" == Jerry James <james(a)xemacs.org&gt; writes: JJ> Steve Youngs <youngs(a)xemacs.org&gt; wrote: JJ> It's there because I made the modules buildable in any of these 3 JJ> situations: JJ> a) as part of the core in a --without-modules XEmacs; JJ> b) as modules built at the same time as the core in a --with-modules JJ> XEmacs; and JJ> c) as modules built independently of the core XEmacs distribution. OK, fair enough. JJ> I keep hearing noises about people working on autoconf 2.5x JJ> support for the core, so I hope that the core will catch up at JJ> some point. Yes, me too. JJ> So now we need to figure out why it isn't working that way for you. JJ> Here's a shot in the dark: is the cvs checkout procedure automatically JJ> running autoconf for you on the module configure.ac files? If so, I can JJ> well imagine that there is top-level configure or makefile magic that JJ> says, "run all configure scripts in subdirectories". I wouldn't think so. I normally: (cvs-update "/some/path/" t) Or just plain 'cvs up' from the command line. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "JJ" == Jerry James <james(a)xemacs.org&gt; writes: JJ> I would really like to have you check for the presence of the JJ> configure scripts and evidence that they have been executed JJ> (existence of config.something) after each of the following JJ> steps: JJ> (1) Fresh checkout from CVS ,----[ cvs co xemacs && find ./modules/ -name "config*" -print ] | ./modules/ldap/configure | ./modules/ldap/configure.ac | ./modules/postgresql/configure | ./modules/postgresql/configure.ac | ./modules/sample/external/configure.ac | ./modules/sample/internal/configure.ac `---- JJ> (2) Top-level configure ,----[ ./configure --funky-opts && find ./modules/ -name "config*" -print ] | ./modules/ldap/configure | ./modules/ldap/configure.ac | ./modules/postgresql/configure | ./modules/postgresql/configure.ac | ./modules/sample/external/configure.ac | ./modules/sample/internal/configure.ac `---- JJ> (3) Top-level make ,----[ make && find ./modules/ -name "config*" -print ] | ./modules/ldap/configure | ./modules/ldap/configure.ac | ./modules/postgresql/configure | ./modules/postgresql/configure.ac | ./modules/sample/external/configure.ac | ./modules/sample/internal/configure.ac `---- -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "JJ" == Jerry James <james(a)xemacs.org&gt; writes: JJ> But the configure scripts have NOT been run! So that isn't the JJ> cause of the problem. Hmmmmmm..... I'm becoming very puzzled, JJ> Steve. Is there any chance that you have a stray ellcc in your JJ> PATH? I don't think that could be the cause either, because in ./modules/postgresql/Makefile there is 'CC=../../lib-src/ellcc'. So it wouldn't matter what's in the path. Would you like SSH access to my box so you can see if you can't turn anything up? -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

Jerry> (1) the module autoconf stuff is completely independent Jerry> from the core XEmacs autoconf stuff, so it might as well Jerry> use the latest and greatest Wrong. Don't upgrade requirements to >= while something else (the core, yet!) requires <=. It's a massive pain in the ass, because some people won't have one or the other, and those who have both will make varying decisions about the default. If that file works with autoconf 2.13, just copy it to configure.in. Jerry> Here's a shot in the dark: is the cvs checkout procedure Jerry> automatically running autoconf for you on the module Jerry> configure.ac files? No. CVS doesn't do that, unless you make a wrapper script AFAIK. Jerry> If so, I can well imagine that there is top-level configure Jerry> or makefile magic that says, "run all configure scripts in Jerry> subdirectories". Running defaults is easy. But what happens when somebody adds options to one of the configure sub-scripts? How do they get passed? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Jerry> "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; wrote: Jerry> If it was intended to be used by or with the core in any Jerry> way, I would agree. It's not a question of the code produced, it's a question of "do we need to cause annoyance to testers and sysadmins who may have good reasons to want to use modules?" I don't think we should. I think it would be best to stick to autoconf 2.13, but I don't want to make you do extra work when there's a reasonable chance that 22.0 will use autoconf 2.5x. Is it known to be unreasonable for simple autoconf.in's to be compatible with both 2.13 and 2.5x? Jerry> But those configure scripts are only to be used when the Jerry> module is built independently of the core OK. Maybe they need to check the installed XEmacs for the error behavior? (Yes, I know that's a hairball....) Er, wait a sec ... do they produce their own config.h? That's not good. How about a --use-config-h=REQUIRED_FILE_SPEC option, which defaults to `xemacs -vanilla -batch -eval '(princ exec-directory)'`include/config.h`? If that XEmacs uses pdump, you could also build in the pdump-id to make sure the binary and the modules correspond (I think, I don't really understand the pdump-id). Jerry> We could remove the ability to build the modules separately Jerry> for now, if that seems wise to the other developers. I don't think so. We are either going to face this breakage eventually, or give up on independent modules. But (aside from RMS's bete noire of a backdoor through the GPL), packaging ELLs is the main generic[1] reason for doing this, right? Let's do it now; someone who's not working on modules can always get a working XEmacs with ./configure --with-modules=no, right? The problem is that the modules evidently depend on the configuration of the XEmacs they run with. We need to understand why and fix the API / advice to modules programmers / ABI. Footnotes: [1] I know you and Andy Begel have other reasons for wanting modules, I'm talking about why the rest of us want them. ;-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py