* Re: Mac OS X 10.2.2 - Need to Recompile
[not found] <20021112092211.24610.36860.Mailman@monty-python.gnu.org>
@ 2002-11-12 14:39 ` Brad Miller
2002-11-12 16:16 ` Steven Tamm
2002-11-12 16:42 ` Andrew Choi
0 siblings, 2 replies; 13+ messages in thread
From: Brad Miller @ 2002-11-12 14:39 UTC (permalink / raw)
I had the same problem this morning after updating to 10.2.2 last night.
My first attempt, was to do something simple:
make clean
make
That didn't solve it... Emacs still died right after launch.
make distclean
make
Same result. For some reason this never works like I would expect it
to for the mac build. Is there a better/different clean target that I
should use?
So, I removed the emacs directory and checked out a clean copy from CVS.
./configure --without-x
make bootstrap
Now I get a bunch of warnings like this one, chosen at random:
keyboard.c:62: warning: could not use precompiled header
'/usr/include/unistd-gcc3.p', because:
keyboard.c:62: warning: macro 'select' defined by ./s/darwin.h
conflicts with precomp
Finally the compile dies a horrible death at:
Compiling /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el
>>Error occurred processing
/Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el: Symbol's function
definition is void ((char-table-p))
make[1]: *** [compile] Error 1
make: *** [bootstrap] Error 2
Uggh! Now I'm really stuck. Any thoughts on what I can do?
Thanks,
Brad
On Tuesday, November 12, 2002, at 03:22 AM, emacs-devel-request@gnu.org
wrote:
>
> --__--__--
>
> Message: 7
> Date: Mon, 11 Nov 2002 19:34:24 -0800
> Subject: Mac OS X 10.2.2 - Need to Recompile
> From: Steven Tamm <steventamm@mac.com>
> To: emacs-devel@gnu.org
>
> I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled
> in 10.2.1) stopped working (similar to the update between 10.1 and
> 10.2). Recompiling fixed everything, so it's not a huge problem.
> Seems that there is a new version of libSystem.B included in 10.2.2,
> which is incompatible.
>
> The error I got was here:
>
> #0 0x90004248 in szone_size ()
> #1 0x000b0b0c in xrealloc (block=0x0, size=321) at alloc.c:542
> #2 0x00006240 in adjust_frame_message_buffer (f=0x63aec0) at
> dispnew.c:2435
> #3 0x00005c20 in adjust_frame_glyphs (f=0x63aec0) at dispnew.c:2133
> #4 0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
> #5 0x0000c6e4 in init_display () at dispnew.c:6537
>
> It occurs on the first call to realloc with a non-empty block. The
> darwin source is hard to follow at this point as malloc blocks are
> controlled in objc code.
>
> Does anyone else see this problem?
> -Steven
>
>
Brad Miller
PhD Candidate
University of Minnesota
(612) 384-8351
http://www-users.cs.umn.edu/~bmiller
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Mac OS X 10.2.2 - Need to Recompile
2002-11-12 14:39 ` Mac OS X 10.2.2 - Need to Recompile Brad Miller
@ 2002-11-12 16:16 ` Steven Tamm
2002-11-12 16:42 ` Andrew Choi
1 sibling, 0 replies; 13+ messages in thread
From: Steven Tamm @ 2002-11-12 16:16 UTC (permalink / raw)
Cc: emacs-devel
FWIW, I got it to work by just relinking. I removed src/emacs and then
"make" rerunning make from a two week old version of CVS.
> Now I get a bunch of warnings like this one, chosen at random:
> keyboard.c:62: warning: could not use precompiled header
> '/usr/include/unistd-gcc3.p', because:
> keyboard.c:62: warning: macro 'select' defined by ./s/darwin.h
> conflicts with precomp
This warning is OK. Select is overridden on Mac OS X to deal with a
small problem when carbon emacs is run from the command line. It
should also complain about vfork being overridden. I don't remember
what it was for and I'm not sure if that override is necessary in 10.2.
If it says "precompiled header is out of date" then run
% sudo fixPrecomps
> Finally the compile dies a horrible death at:
> Compiling /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el
> >>Error occurred processing
> /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el: Symbol's function
> definition is void ((char-table-p))
> make[1]: *** [compile] Error 1
> make: *** [bootstrap] Error 2
A couple other people have sent this to me. It appears latest CVS is
broken. I just updated to the latest CVS and run a make bootstrap and
encountered the same problem. I'm going to try to revert to CVS from
two weeks ago and see what happens.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Mac OS X 10.2.2 - Need to Recompile
2002-11-12 14:39 ` Mac OS X 10.2.2 - Need to Recompile Brad Miller
2002-11-12 16:16 ` Steven Tamm
@ 2002-11-12 16:42 ` Andrew Choi
2002-11-14 2:55 ` char-table-p (Re: Mac OS X 10.2.2 - Need to Recompile) Katsumi Yamaoka
1 sibling, 1 reply; 13+ messages in thread
From: Andrew Choi @ 2002-11-12 16:42 UTC (permalink / raw)
Cc: emacs-devel
Brad Miller <bmiller@cs.umn.edu> writes:
> Finally the compile dies a horrible death at:
> Compiling /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el
> >>Error occurred processing
> /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el: Symbol's
> function definition is void ((char-table-p))
> make[1]: *** [compile] Error 1
> make: *** [bootstrap] Error 2
>
> Uggh! Now I'm really stuck. Any thoughts on what I can do?
The current CVS code does not bootstrap correctly. It has already been
reported in gnu.emacs.help.
^ permalink raw reply [flat|nested] 13+ messages in thread
* char-table-p (Re: Mac OS X 10.2.2 - Need to Recompile)
2002-11-12 16:42 ` Andrew Choi
@ 2002-11-14 2:55 ` Katsumi Yamaoka
0 siblings, 0 replies; 13+ messages in thread
From: Katsumi Yamaoka @ 2002-11-14 2:55 UTC (permalink / raw)
Cc: jun, akochoi, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
Hi,
Jun'ichi Shiono <jun@fsas.fujitsu.com> has found the cause of
the "Symbol's function definition is void ((char-table-p))"
problem. He said that building Emacs CVS as bootstrap is
successful if he canceled the following change:
2002-11-06 Dave Love <fx@gnu.org>
[...]
* international/mule.el (set-buffer-file-coding-system):
Call ucs-set-table-for-input.
>>>>> In <m2k7jig2np.fsf@owlbear.local>
>>>>> akochoi@shaw.ca (Andrew Choi) wrote:
> Brad Miller <bmiller@cs.umn.edu> writes:
>> Finally the compile dies a horrible death at:
>> Compiling /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el
>> >>Error occurred processing
>> /Users/bmiller/src/emacs/lisp/progmodes/cc-mode.el: Symbol's
>> function definition is void ((char-table-p))
>> make[1]: *** [compile] Error 1
>> make: *** [bootstrap] Error 2
>> Uggh! Now I'm really stuck. Any thoughts on what I can do?
> The current CVS code does not bootstrap correctly. It has already been
> reported in gnu.emacs.help.
Here's a reverse patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 589 bytes --]
*** mule.el~ Wed Nov 6 23:59:53 2002
--- mule.el Thu Nov 14 02:50:59 2002
***************
*** 1179,1188 ****
(setq coding-system
(merge-coding-systems coding-system buffer-file-coding-system)))
(setq buffer-file-coding-system coding-system)
- ;; This is in case of an explicit call. Normally, `normal-mode' and
- ;; `set-buffer-major-mode-hook' take care of setting the table.
- (if (fboundp 'ucs-set-table-for-input) ; don't lose when building
- (ucs-set-table-for-input))
(set-buffer-modified-p t)
(force-mode-line-update))
--- 1179,1184 ----
^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20021114202626.11156.14764.Mailman@monty-python.gnu.org>]
* Re: Mac OS X 10.2.2 - Need to Recompile
[not found] <20021114202626.11156.14764.Mailman@monty-python.gnu.org>
@ 2002-11-15 10:01 ` Mikael Krantz
2002-11-15 12:51 ` Mikael Krantz
0 siblings, 1 reply; 13+ messages in thread
From: Mikael Krantz @ 2002-11-15 10:01 UTC (permalink / raw)
On Thu, 14 Nov 2002, Steven Tamm wrote:
> For those who still have a bad binary, could you check to see if
> setting the environment variable DYLD_FORCE_FLAT_NAMESPACE fixes
> anything? I have a sneaky suspicion it might; but it could also fail
> due to redefinition of some terminfo variables BC, PC, and UP.
Well, it fixes something... at least now it breaks in another way (due to
redefinition of BC it seems).
More info:
I've tried to bootstrap from CVS (latest, 2002-11-01 and 2002-09-27) with
similar results:
make bootstrap fails with:
../src/bootstrap-emacs -batch --no-site-file --multibyte -l autoload
--eval '(setq generated-autoload-file "/Users/mk/emacs/lisp/loaddefs.el")'
-f batch-update-autoloads $wins
Directories: /Users/mk/emacs/lisp /Users/mk/emacs/lisp/calc
/Users/mk/emacs/lisp/calendar /Users/mk/emacs/lisp/emacs-lisp
/Users/mk/emacs/lisp/emulation /Users/mk/emacs/lisp/eshell
/Users/mk/emacs/lisp/gnus /Users/mk/emacs/lisp/international
/Users/mk/emacs/lisp/language /Users/mk/emacs/lisp/mail
/Users/mk/emacs/lisp/net /Users/mk/emacs/lisp/obsolete
/Users/mk/emacs/lisp/play /Users/mk/emacs/lisp/progmodes
/Users/mk/emacs/lisp/term /Users/mk/emacs/lisp/textmodes
/Users/mk/emacs/lisp/toolbar
make[1]: *** [autoloads] Error 139
make: *** [bootstrap] Error 2
closer examination (gdb) yields that bootstrap-emacs segfaults when
initializing dyld:
(gdb) run
Starting program: /Users/mk/emacs/src/bootstrap-emacs
[Switching to process 7017 thread 0xb03]
Reading symbols for shared libraries
................................................. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x8fe0d53c in __dyld_lookup_symbol ()
(gdb) bt
#0 0x8fe0d53c in __dyld_lookup_symbol ()
#1 0x8fe0baac in __dyld_resolve_undefineds ()
#2 0x8fe10614 in __dyld_link_in_need_modules ()
#3 0x8fe014e4 in __dyld__dyld_init ()
(gdb)
If I define DYLD_FORCE_FLAT_NAMESPACE it fails with:
bash-2.05$ env DYLD_FORCE_FLAT_NAMESPACE= src/bootstrap-emacs
dyld: src/bootstrap-emacs multiple definitions of symbol _BC
src/bootstrap-emacs definition of _BC
/usr/lib/libncurses.5.dylib(lib_termcap.o) definition of _BC
Trace/BPT trap
As you suspected.
I'm using 10.2.2 with latest developer tools (gcc 3.1).
/Mikael Krantz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Mac OS X 10.2.2 - Need to Recompile
2002-11-15 10:01 ` Mac OS X 10.2.2 - Need to Recompile Mikael Krantz
@ 2002-11-15 12:51 ` Mikael Krantz
0 siblings, 0 replies; 13+ messages in thread
From: Mikael Krantz @ 2002-11-15 12:51 UTC (permalink / raw)
On Fri, 15 Nov 2002, Mikael Krantz wrote:
> On Thu, 14 Nov 2002, Steven Tamm wrote:
> > For those who still have a bad binary, could you check to see if
> > setting the environment variable DYLD_FORCE_FLAT_NAMESPACE fixes
> > anything? I have a sneaky suspicion it might; but it could also fail
> > due to redefinition of some terminfo variables BC, PC, and UP.
>
> Well, it fixes something... at least now it breaks in another way (due to
> redefinition of BC it seems).
>
> More info:
>
> I've tried to bootstrap from CVS (latest, 2002-11-01 and 2002-09-27) with
> similar results:
> ...
> closer examination (gdb) yields that bootstrap-emacs segfaults when
> initializing dyld:
It seems that there was a problem with MacOS X rather than emacs itself.
Doing a "Repair permissions" in Discutil followed by a reboot made it go
away.
DYLD_FORCE_FLAT_NAMESPACE still fails, though the binary runs fine without
it :)
Sorry for any confusion I may have caused.
/Mikael Krantz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Mac OS X 10.2.2 - Need to Recompile
@ 2002-11-13 0:06 Dan Brotsky
0 siblings, 0 replies; 13+ messages in thread
From: Dan Brotsky @ 2002-11-13 0:06 UTC (permalink / raw)
> I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled
> in 10.2.1) stopped working (similar to the update between 10.1 and
> 10.2).
This is exactly what happened to me. Unfortunately I don't have a crash
log handy, but as in your case it was a realloc underneath init_display.
Doing a clean recompile (make clean; make) fixed the problem (as you
report happening in your case).
dan
> Recompiling fixed everything, so it's not a huge problem.
> Seems that there is a new version of libSystem.B included in 10.2.2,
> which is incompatible.
>
> The error I got was here:
>
> #0 0x90004248 in szone_size ()
> #1 0x000b0b0c in xrealloc (block=0x0, size=321) at alloc.c:542
> #2 0x00006240 in adjust_frame_message_buffer (f=0x63aec0) at
> dispnew.c:2435
> #3 0x00005c20 in adjust_frame_glyphs (f=0x63aec0) at dispnew.c:2133
> #4 0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
> #5 0x0000c6e4 in init_display () at dispnew.c:6537
>
> It occurs on the first call to realloc with a non-empty block. The
> darwin source is hard to follow at this point as malloc blocks are
> controlled in objc code.
>
> Does anyone else see this problem?
> -Steven
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Mac OS X 10.2.2 - Need to Recompile
@ 2002-11-13 0:05 Dan Brotsky
0 siblings, 0 replies; 13+ messages in thread
From: Dan Brotsky @ 2002-11-13 0:05 UTC (permalink / raw)
> I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled
> in 10.2.1) stopped working (similar to the update between 10.1 and
> 10.2).
This is exactly what happened to me. Unfortunately I don't have a crash
log handy, but as in your case it was a realloc underneath init_display.
Doing a clean recompile (make clean; make) fixed the problem (as you
report happening in your case).
dan
> Recompiling fixed everything, so it's not a huge problem.
> Seems that there is a new version of libSystem.B included in 10.2.2,
> which is incompatible.
>
> The error I got was here:
>
> #0 0x90004248 in szone_size ()
> #1 0x000b0b0c in xrealloc (block=0x0, size=321) at alloc.c:542
> #2 0x00006240 in adjust_frame_message_buffer (f=0x63aec0) at
> dispnew.c:2435
> #3 0x00005c20 in adjust_frame_glyphs (f=0x63aec0) at dispnew.c:2133
> #4 0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
> #5 0x0000c6e4 in init_display () at dispnew.c:6537
>
> It occurs on the first call to realloc with a non-empty block. The
> darwin source is hard to follow at this point as malloc blocks are
> controlled in objc code.
>
> Does anyone else see this problem?
> -Steven
^ permalink raw reply [flat|nested] 13+ messages in thread
* Mac OS X 10.2.2 - Need to Recompile
@ 2002-11-12 3:34 Steven Tamm
2002-11-13 10:05 ` Thorbjørn Ravn Andersen
2002-11-13 11:33 ` Richard Stallman
0 siblings, 2 replies; 13+ messages in thread
From: Steven Tamm @ 2002-11-12 3:34 UTC (permalink / raw)
I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled
in 10.2.1) stopped working (similar to the update between 10.1 and
10.2). Recompiling fixed everything, so it's not a huge problem.
Seems that there is a new version of libSystem.B included in 10.2.2,
which is incompatible.
The error I got was here:
#0 0x90004248 in szone_size ()
#1 0x000b0b0c in xrealloc (block=0x0, size=321) at alloc.c:542
#2 0x00006240 in adjust_frame_message_buffer (f=0x63aec0) at
dispnew.c:2435
#3 0x00005c20 in adjust_frame_glyphs (f=0x63aec0) at dispnew.c:2133
#4 0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
#5 0x0000c6e4 in init_display () at dispnew.c:6537
It occurs on the first call to realloc with a non-empty block. The
darwin source is hard to follow at this point as malloc blocks are
controlled in objc code.
Does anyone else see this problem?
-Steven
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Mac OS X 10.2.2 - Need to Recompile
2002-11-12 3:34 Steven Tamm
@ 2002-11-13 10:05 ` Thorbjørn Ravn Andersen
2002-11-13 11:33 ` Richard Stallman
1 sibling, 0 replies; 13+ messages in thread
From: Thorbjørn Ravn Andersen @ 2002-11-13 10:05 UTC (permalink / raw)
Cc: emacs-devel
Steven Tamm wrote:
> I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled
> in 10.2.1) stopped working (similar to the update between 10.1 and
> 10.2). Recompiling fixed everything, so it's not a huge problem.
> Seems that there is a new version of libSystem.B included in 10.2.2,
> which is incompatible.
>
> The error I got was here:
>
> #0 0x90004248 in szone_size ()
> #1 0x000b0b0c in xrealloc (block=0x0, size=321) at alloc.c:542
> #2 0x00006240 in adjust_frame_message_buffer (f=0x63aec0) at
> dispnew.c:2435
> #3 0x00005c20 in adjust_frame_glyphs (f=0x63aec0) at dispnew.c:2133
> #4 0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
> #5 0x0000c6e4 in init_display () at dispnew.c:6537
>
> It occurs on the first call to realloc with a non-empty block. The
> darwin source is hard to follow at this point as malloc blocks are
> controlled in objc code.
>
> Does anyone else see this problem?
Yes. My Emacs did the same.
In gdb with "-nw" the stack trace is as follows:
#0 0x90004248 in szone_size ()
#1 0x000b0e30 in xrealloc (block=0x0, size=481) at alloc.c:542
#2 0x00006240 in adjust_frame_message_buffer (f=0x645ec0) at dispnew.c:2435
#3 0x00005c20 in adjust_frame_glyphs (f=0x645ec0) at dispnew.c:2133
#4 0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
#5 0x0000c6e4 in init_display () at dispnew.c:6537
#6 0x00061b4c in main (argc=2, argv=0xbffffb98, envp=0x0) at emacs.c:1544
#7 0x000038a8 in _start (argc=50, argv=0x2, envp=0x23b284) at
/SourceCache/Csu/Csu-45/crt.c:267
#8 0x00003728 in start ()
Then trying to restart with a file name:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x90013b70 in large_entry_for_pointer_no_lock ()
(gdb) bt
#0 0x90013b70 in large_entry_for_pointer_no_lock ()
#1 0x90004204 in szone_size ()
#2 0x000b0e30 in xrealloc (block=0x0, size=41) at alloc.c:542
#3 0x00006240 in adjust_frame_message_buffer (f=0x645ec0) at dispnew.c:2435
#4 0x00005c20 in adjust_frame_glyphs (f=0x645ec0) at dispnew.c:2133
#5 0x00005bcc in adjust_frame_glyphs_initially () at dispnew.c:2115
#6 0x00061b4c in main (argc=2, argv=0xbffffb98, envp=0x646) at emacs.c:1544
#7 0x000038a8 in _start (argc=50, argv=0x2, envp=0x23b284) at
/SourceCache/Csu/Csu-45/crt.c:267
#8 0x00003728 in start ()
I'll save this binary if you need me to do additional testing.
--
Thorbjørn Ravn Andersen Scandiatransplant
Skejby Sygehus, indgang 3
+45 89 49 53 01 DK-8200 Århus N
http://biobase.dk/~tra
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Mac OS X 10.2.2 - Need to Recompile
2002-11-12 3:34 Steven Tamm
2002-11-13 10:05 ` Thorbjørn Ravn Andersen
@ 2002-11-13 11:33 ` Richard Stallman
2002-11-14 8:12 ` Steven Tamm
1 sibling, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2002-11-13 11:33 UTC (permalink / raw)
Cc: emacs-devel
I just updated to Mac OS X 10.2.2 and the emacs I was using (compiled
in 10.2.1) stopped working (similar to the update between 10.1 and
10.2). Recompiling fixed everything, so it's not a huge problem.
Could you write a note for etc/PROBLEMS?
If you can fix the problem, that is good, but not desperately
necessary; however, it is important to have that note.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Mac OS X 10.2.2 - Need to Recompile
2002-11-13 11:33 ` Richard Stallman
@ 2002-11-14 8:12 ` Steven Tamm
2002-11-15 13:46 ` Thorbjørn Ravn Andersen
0 siblings, 1 reply; 13+ messages in thread
From: Steven Tamm @ 2002-11-14 8:12 UTC (permalink / raw)
Cc: emacs-devel
Done. Here it is.
* Emacs crashes on Mac OS X (Carbon) after system software upgrade.
Between Mac OS X release 10.2.1 and 10.2.2 there was an incompatible
change in the memory allocator that causes a EXC_BAD_ACCESS error near
xrealloc(). Relinking the application (by deleting src/temacs and
running make) will solve the problem. It appears to be caused by some
problems with the unexec code and its interaction with libSystem.B.
-----
I researched the problem and it appears to be related to the
unexmacosx.c code. I need to compare more the unexdyld.c code from
apple (which provided an upwardly compatibly release) with how
unexmacosx works. Hopefully darwin will get a little more stable so
that the incompatible changes won't happen so frequently.
For those who still have a bad binary, could you check to see if
setting the environment variable DYLD_FORCE_FLAT_NAMESPACE fixes
anything? I have a sneaky suspicion it might; but it could also fail
due to redefinition of some terminfo variables BC, PC, and UP.
-Steven
P.S. I spent a little bit of time trying to get unexdyld.c to work
with the Carbon GUI. As Andrew's comments in unexmacosx.c explain, the
use of malloc_freezedry and malloc_jumpstart exist in
Next/Openstep/rhapsody/darwin solely for the purpose of emacs unexec.
However, it appears that any use of the CoreFoundtation layer (which
Carbon uses extensively) causes malloc_freezedry to break. The
unexmacosx.c code does pretty much the same thing that freezedry does,
but with a finer degree of control by using the primitives in
scaleable_malloc directly. However, if you try to update_prebinding on
an emacs binary, it complains that hints table is out of place.
Running otool -l on the Apple provided binary next to one from CVS
yields a very, very different story. More investigation into this is
needed.
On Wednesday, November 13, 2002, at 03:33 AM, Richard Stallman wrote:
> I just updated to Mac OS X 10.2.2 and the emacs I was using
> (compiled
> in 10.2.1) stopped working (similar to the update between 10.1 and
> 10.2). Recompiling fixed everything, so it's not a huge problem.
>
> Could you write a note for etc/PROBLEMS?
> If you can fix the problem, that is good, but not desperately
> necessary; however, it is important to have that note.
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Mac OS X 10.2.2 - Need to Recompile
2002-11-14 8:12 ` Steven Tamm
@ 2002-11-15 13:46 ` Thorbjørn Ravn Andersen
0 siblings, 0 replies; 13+ messages in thread
From: Thorbjørn Ravn Andersen @ 2002-11-15 13:46 UTC (permalink / raw)
Cc: rms, emacs-devel
Steven Tamm wrote:
>
> For those who still have a bad binary, could you check to see if
> setting the environment variable DYLD_FORCE_FLAT_NAMESPACE fixes
> anything? I have a sneaky suspicion it might; but it could also fail
> due to redefinition of some terminfo variables BC, PC, and UP.
>
For me the following happens:
[sc147:~] ravn% setenv DYLD_FORCE_FLAT_NAMESPACE
[sc147:~] ravn% /usr/local/bin/emacs-21.3.50.crashes-under-1022
dyld: /usr/local/bin/emacs-21.3.50.crashes-under-1022 multiple
definitions of symbol _BC
/usr/local/bin/emacs-21.3.50.crashes-under-1022 definition of _BC
/usr/lib/libncurses.5.dylib(lib_termcap.o) definition of _BC
Trace/BPT trap
[sc147:~] ravn% unsetenv DYLD_FORCE_FLAT_NAMESPACE
[sc147:~] ravn% /usr/local/bin/emacs-21.3.50.crashes-under-1022
Fatal error (11).Segmentation fault
[sc147:~] ravn%
--
Thorbjørn Ravn Andersen Scandiatransplant
Skejby Sygehus, indgang 3
+45 89 49 53 01 DK-8200 Århus N
http://biobase.dk/~tra
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2002-11-15 13:46 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20021112092211.24610.36860.Mailman@monty-python.gnu.org>
2002-11-12 14:39 ` Mac OS X 10.2.2 - Need to Recompile Brad Miller
2002-11-12 16:16 ` Steven Tamm
2002-11-12 16:42 ` Andrew Choi
2002-11-14 2:55 ` char-table-p (Re: Mac OS X 10.2.2 - Need to Recompile) Katsumi Yamaoka
[not found] <20021114202626.11156.14764.Mailman@monty-python.gnu.org>
2002-11-15 10:01 ` Mac OS X 10.2.2 - Need to Recompile Mikael Krantz
2002-11-15 12:51 ` Mikael Krantz
2002-11-13 0:06 Dan Brotsky
-- strict thread matches above, loose matches on Subject: below --
2002-11-13 0:05 Dan Brotsky
2002-11-12 3:34 Steven Tamm
2002-11-13 10:05 ` Thorbjørn Ravn Andersen
2002-11-13 11:33 ` Richard Stallman
2002-11-14 8:12 ` Steven Tamm
2002-11-15 13:46 ` Thorbjørn Ravn Andersen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).