GNU bug report logs - #7387
23.2; Emacs port to HP-UX ia64

Previous Next

Full log

Message #20 received at 7387 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Maguire\, Andrew \(GE Energy\)" <andrew.maguire <at> ge.com>
Cc: 7387 <at> debbugs.gnu.org
Subject: Re: bug#7387: 23.2; Emacs port to HP-UX ia64
Date: Fri, 12 Nov 2010 16:28:16 -0500

> I have been attempting a port to Itanium HP-UX 11.23.

The configuration files for different OSes and hardware have been
changed significantly (tho not completely) in the trunk (to become
Emacs-24), so you may want to work directly in that version instead
(otherwise someone may additionally have to figure out how to port the
patch you come up with for Emacs-23)

> I have managed to change the configure etc. to successfully produce a
> seemingly
> valid bootstrap-emacs executable.
> However, when it runs it immediately returns the error:

> 	emacs: Invalid function: run-hooks

Placing a breakpoint on Fsignal may help you figure out what's going on.
[ Oh, I saw later that GDB is not functional for you.  Hmm... ]

> This at a guess implies it is running the low level C functions but
> appears to be
> failing to find the Lisp function binding.

Everything's possible, but run-hooks is a C function, not a Lisp
function; and some C code runs Frun_hooks via an indirection through the
"run-hooks" symbol itself found via the Vrun_hooks C-only variable.
So it's quite possible (my gut says "likely") that it's still a C-level
problem.

IOW I think the issue is that for some reason Vrun_hooks was set to the
"run-hooks" symbol before the Frun_hooks function was defined (via the
defsubr call in syms_of_eval).  As it turns out Vrun_hooks is also set
in syms_of_eval.

So that would imply that the above error would happen some time between
the
    Vrun_hooks = intern_c_string ("run-hooks");
and
    defsubr (&Srun_hooks);

in syms_of_eval.  Nothing there jumps at me as a likely culprit, so
maybe the issue is that Vrun_hooks gets set elsewhere, or that
DEFUN+defsubr don't actually do their job as expected.  E.g. maybe the
data section that holds the Lisp_Subr structures gets wiped by the dump?

> I noticed that XEmacs has a portable dump feature, which essentially
> avoids rewriting an executable file but instead stores the Lisp data
> to an xemacs.dmp file next to the executable.

Yes, quite handy, isn't it?

> I managed to build XEmacs 21.4.22 using it on the machine, but I want
> FSF Emacs!

Of course, don't we all?


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.