>>I can't remember the dynamic solution. I don't recall what I did. I feel
>really stupid for not remembering. I think I worked around it in some
>way. I am almost positive I did not use the sun file. I may have even opted
>for static linking. The error probably has to do with the temacs to emacs
>stage where the lisp is loaded and dumped as part of a new, larger 
>executable. I think the DYNAMIC code hunts for the beginning of
>the data segment. You might want to see if there is any bsd equivalent
>for that sunexec stuff. If you are still stuck tonight I may try to juggle
>some disk space and see if I can retrace my steps.
>
>--Rod

 Well, I did get stuck again last night. First, here is what tthe output of 
 
 "file /usr/local/bin/emacs" command is

 " emacs NetBSD/m68k demand paged dynamically linked executable not stripped".

 I then read through some problems related documentation in the
distribution. There was a suggestion to try not using systems malloc (on
suns). So I added

 "#UNDEFINE SYSTEM_MALLOC" to the config.h header. Linking still found
looking for __DYNAMIC stuff, so I took away -nostandlib from the final step
of gcc. And I got a new emacs executable. It does not run. When I try to
run it, I get;

 " Abort trap".

Well, after that my system is having problems getting back up. I think I
screwed up the file system during installation of all the stuff by gmake
install step into /usr/local. I can not get it stable yet. Kernel is
hanging after rebooting.
I tried from 12:00 am untill 2:00 am, just to bring up the system up.

Anyway, the output of "file emacs" command for this emacs with  the
SYSTEM_MALLOC UNDEFINED is still the same.

" emacs NetBSD/m68k demand paged dynamically linked executable not stripped".

Let me know if you have any suugestions.

Sincerely:


  
Bharat S. Jhaveri       
bjhaveri@arco.com


------------------------------------------------------------------------------