>>>> "WMP" == William M Perry
<wmperry(a)aventail.com> writes:
WMP> Martin Buchholz <martin(a)xemacs.org> writes:
> >>>>> "B" == William M Perry
<wmperry(a)aventail.com> writes:
>
B> Nils Bokermann <bokerman(a)uni-bielefeld.de> writes:
> >> On Wed, Nov 24, 1999 at 12:15:00PM +0100, Jan Vroonhof
wrote:
> >> > I think wmperry had a similar problem recently. on some
> >> > Solaris 2.6 versions the dldump library doesn't work that
> >> > well...
> >> >
> >> > I think the work around would be to change .../src/s/sol2.h
> >> > from
> >> >
> >> > #undef UNEXEC if OS_RELEASE < 56 define UNEXEC
"unexsol2.o"
> >> > #else define UNEXEC "unexsol2-6.o" endif
> >> >
> >> > to
> >> >
> >> > #undef UNEXEC if OS_RELEASE < 56 define UNEXEC
"unexsol2.o"
> >> > #else define UNEXEC "unexsol2.o" endif
> >> >
> >> > Could you report back if this works for you too?
> >>
> >> Hmm -- but this won't work too :( Finding pointers to doc
> >> strings...done Dumping under the name xemacs Segmentation Fault
> >> - core dumped
> >> *** Error code 139 (ignored)
> >> ...
>
B> Did you completely reconfigure? You have to regenerate EVERYTHING
B> for this change to take effect.
>
> It seems highly unlikely that the unexec's for Solaris have to be
> changed. This stuff has worked for years, at least for Solaris <
> 2.7. "Georg Nikodym <georg.nikodym(a)sun.com>" is the expert.
> There has to be a lot of evidence to the contrary. So I veto this
> patch for the time being.
WMP> The sparcbook is the only 2.6 or higher box I have access to,
WMP> and I was never able to build successfully on it using the
WMP> built-in dldump() support in unexsol2-6.c
WMP> I've seen other posts on comp.emacs.xemacs about similar build
WMP> failures, that were on non-sparcbook machines though.
If somebody can provide me with enough information that I might
reasonably attempt to re-produce this problem then I'd be happy
to investigate.
Specifically, the information I'm looking for is:
- solaris version, including patches (showrev -p will list the
latter)
- hardware platform info
- gcc version (and any relevant info about config)
- xemacs version and complete configuration info
However, the best outcome is that I'll start the wheels turning on a
patch. If using dynodump (the pre-2.6 Solaris dumping code) works for
these problem cases, then maybe a switch in configure would be better?