[ Note: I'm sending this message to get it into the archives, so that
others will hopefully not waste hours tracking this down. ]
[ Note^2: although I work for HP, the following is *UNOFFICIAL* and
*UNSUPPORTED*. This merely reflects my own personal experiences in
trying to get XEmacs working under HP-UX. ]
***** Problem:
Under HP-UX 10.20, with native audio enabled, the undumped XEmacs
binary core dumps when run (temacs runs fine). This, of course, causes
the XEmacs build to fail. If GNU malloc is enabled, a stack trace will
show XEmacs to have crashed in the first call to malloc().
This bug currently exists in all versions of XEmacs.
***** Cause:
Recent versions of the HP-UX 10.20 audio shared library (in
/opt/audio/lib), pulls in the libdce shared library, which pulls in a
thread (libcma) library. This exposes a bug in the HP-UX undump()
routine (in unexhp9k800.c). The result is that the libcma library
truncates the data segment at startup (before main() is entered!), which
quickly causes XEmacs to crash. [ The issue is that the libcma library
is somehow computing an address just past the end of BSS, and this
address is wrong, probably because unexhp9k800.c has not fixed up all of
the necessary headers in the undumped executable. (Unfortunately, I've
stared and stared at the headers, and I can't tell what needs to be
fixed.) ]
I believe versions of the audio library past December 1998 will
trigger this problem, and I believe that you have to install audio
library patches to encounter this. I'm not sure, but I think the audio
patch PHSS_17121 (or a superceeding one, like PHSS_17554, PHSS_17971, or
PHSS_18777, etc.) will trigger this. To check if your audio library
will cause problems for XEmacs, run "chatr /opt/audio/lib/libAlib.sl".
If "libdce" appears in the displayed shared library list, XEmacs will
probably encounter problems if audio is enabled.
***** Workaround:
Don't enable audio. Re-run configure without audio support.
***** Fix:
Unfortunately, I don't have one, and I don't know if I ever will.
Perhaps someone else will come up with one.
--
Darryl Okahata
darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
Show replies by date
[ Note: I'm sending this message to get it into the archives, so that
others will hopefully not waste hours tracking this down. ]
[ Note^2: although I work for HP, the following is *UNOFFICIAL* and
*UNSUPPORTED*. This merely reflects my own personal experiences in
trying to get XEmacs working under HP-UX. ]
OK, I've tracked down the exact cause of my recent build failures
with HP-UX 10.20 and XEmacs, but I'm not sure what to do about it.
The basic problem is that the undumped XEmacs binary immediately
dumps core when run.
The cause is, basically, due to recent versions of the audio shared
library pulling in the libdce library, which pulls in the libcma threads
library. The libcma threads library redefines _start and calls sbrk()
(*before* main() is called!) before XEmacs has had a chance to properly
adjust the brk() value (via Restore_Shared_Data() in src/unexhp9k800.c).
The result is that the call to sbrk() truncates the data segment. To
not crash, the undumped XEmacs binary needs to adjust the brk() value,
but it's never getting a chance to do so, as libcma is calling sbrk()
before main() is even entered.
To encounter this crash, you must have enabled native sound in
XEmacs and be using a recent version of the audio shared library. Older
versions do not pull in the libdce library.
I believe versions of the audio library past December 1998 will
trigger this problem, and I believe that you have to install audio
library patches to encounter this. I'm not sure, but I think the audio
patch PHSS_17121 (or a superceeding one, like PHSS_17554, PHSS_17971, or
PHSS_18777, etc.) will trigger this. To check if your audio library
will cause problems for XEmacs, run "chatr /opt/audio/lib/libAlib.sl".
If "libdce" appears in the displayed shared library list, XEmacs will
probably encounter problems if audio is enabled.
Disabling the use of shared libraries (i.e., use all archive
libraries only) is an obvious solution, but the HP-UX audio library only
comes in shared form; a static archive version is not available.
Unfortunately, without resorting to some really ugly code, I think
this means that XEmacs can no longer use recent/newer versions of the
audio library under HP-UX 10.20; native audio can no longer be used. I
guess the "fix" is to not enable native audio.
I don't know if this issue exists under HP-UX 11.0.
--
Darryl Okahata
darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
Darryl Okahata writes:
I don't know if this issue exists under HP-UX 11.0.
Well, I tried once to include sound support but wasn't too excited
about the result. So I decided not to use it.
--Marcus
Marcus Thiessel writes:
Darryl Okahata writes:
> I don't know if this issue exists under HP-UX 11.0.
Well, I tried once to include sound support but wasn't too excited
about the result. So I decided not to use it.
Why weren't you excited? What would excite you?
Kyle Jones writes:
Marcus Thiessel writes:
> Well, I tried once to include sound support but wasn't too excited
> about the result. So I decided not to use it.
Why weren't you excited? What would excite you?
The reasons why I wasn't too excited were:
-- volume not really adjustable and too low (build-in speakers)
-- playing sounds blocks and freezes XEmacs completely (really
annoying since you hardly hear that sounds are played)
Don't get me wrong on Solaris the sound was quite a good feature and
everything works as expected. I just don't like the behaviour on my
C240.
Since sound is not that important to me I didn't investigate any
further. Could also be that something in the OS or hardware is broken.
--Marcus