* bug#1171: #1171 - ns-version-string - Emacs bug report logs @ 2008-10-21 13:31 Adrian Robert 2008-10-21 15:52 ` Stefan Monnier 0 siblings, 1 reply; 22+ messages in thread From: Adrian Robert @ 2008-10-21 13:31 UTC (permalink / raw) To: 1171 I kind of agree with this, but is there another way to indicate which window system is being used? It's useful for bug reports to know if it's X11 or NS (or Carbon, even though the info is sometimes redundant w/ 22/23 in that case). What about just plain "*Step", or "NS Windowing", or someting like that? ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-21 13:31 bug#1171: #1171 - ns-version-string - Emacs bug report logs Adrian Robert @ 2008-10-21 15:52 ` Stefan Monnier 2008-10-21 22:37 ` Glenn Morris 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2008-10-21 15:52 UTC (permalink / raw) To: Adrian Robert; +Cc: 1171 > I kind of agree with this, but is there another way to indicate which window > system is being used? It's useful for bug reports to know if it's X11 or > NS (or Carbon, even though the info is sometimes redundant w/ 22/23 in that > case). What about just plain "*Step", or "NS Windowing", or someting > like that? The objection was about the "0.9" part, not the *Step part, so yes, *Step is fine. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-21 15:52 ` Stefan Monnier @ 2008-10-21 22:37 ` Glenn Morris 2008-10-22 10:53 ` Yavor Doganov 0 siblings, 1 reply; 22+ messages in thread From: Glenn Morris @ 2008-10-21 22:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: Adrian Robert, 1171 Stefan Monnier wrote: > The objection was about the "0.9" part, not the *Step part, so yes, > *Step is fine. If there is a meaningful version number for the external GNUstep/Mac components (analogous to gtk-version-string) against which Emacs was built, that could also be printed. My complaint is indeed about the hard-coded "0.9". ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-21 22:37 ` Glenn Morris @ 2008-10-22 10:53 ` Yavor Doganov 2008-10-22 12:29 ` Adrian Robert 2008-10-22 13:14 ` Adrian Robert 0 siblings, 2 replies; 22+ messages in thread From: Yavor Doganov @ 2008-10-22 10:53 UTC (permalink / raw) To: Glenn Morris, 1171, Stefan Monnier; +Cc: Adrian Robert Glenn Morris wrote: > > If there is a meaningful version number for the external GNUstep/Mac > components (analogous to gtk-version-string) against which Emacs was > built, that could also be printed. For GNUstep, that would be the Base and GUI versions. Ideally, the GSBackend should also be detected and reported, but that's more complicated as it has to happen at runtime. For Mac OS X I don't have a clue, really. The attached patch works for me, although it might not be entirely correct. 2008-10-22 Yavor Doganov <yavor@gnu.org> (tiny change) * nsterm.m (syms_of_nsterm): Provide GNUstep Base/GUI versions as `ns-version-string'. --- nsterm.m 21 окт 2008 15:50:42 +0300 1.32 +++ nsterm.m 22 окт 2008 13:17:21 +0300 @@ -6382,7 +6382,22 @@ /* TODO: try to move this back into lisp, ns-win.el loaded too late right now */ { - Lisp_Object args[3] = { intern ("ns-version-string"), build_string ("9.0"), +#ifdef NS_IMPL_GNUSTEP + char gnustep_version[40]; + snprintf (gnustep_version, sizeof (gnustep_version), + "(GNUstep Base %u.%u.%u, GUI %u.%u.%u)", + GNUSTEP_BASE_MAJOR_VERSION, GNUSTEP_BASE_MINOR_VERSION, + GNUSTEP_BASE_SUBMINOR_VERSION, + GNUSTEP_GUI_MAJOR_VERSION, GNUSTEP_GUI_MINOR_VERSION, + GNUSTEP_GUI_SUBMINOR_VERSION); +#endif + Lisp_Object args[3] = { intern ("ns-version-string"), +#ifdef NS_IMPL_GNUSTEP + build_string (gnustep_version), +#else + /* TODO: Something appropriate for Mac OS X. */ + build_string ("9.0"), +#endif build_string ("NS Window system port version number.") }; Fdefconst (Flist (3, args)); } ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-22 10:53 ` Yavor Doganov @ 2008-10-22 12:29 ` Adrian Robert 2008-10-22 13:14 ` Adrian Robert 1 sibling, 0 replies; 22+ messages in thread From: Adrian Robert @ 2008-10-22 12:29 UTC (permalink / raw) To: Yavor Doganov; +Cc: 1171, Stefan Monnier Hi, Thanks. I actually have a patch that does this for both, just haven't had time to test yet. I'll try a quick compile and check-in right now since there seems to be a lot of interest in this. On Oct 22, 2008, at 6:53 AM, Yavor Doganov wrote: > Glenn Morris wrote: >> >> If there is a meaningful version number for the external GNUstep/Mac >> components (analogous to gtk-version-string) against which Emacs was >> built, that could also be printed. > > For GNUstep, that would be the Base and GUI versions. Ideally, the > GSBackend should also be detected and reported, but that's more > complicated as it has to happen at runtime. > > For Mac OS X I don't have a clue, really. > > The attached patch works for me, although it might not be entirely > correct. > > > 2008-10-22 Yavor Doganov <yavor@gnu.org> (tiny change) > > * nsterm.m (syms_of_nsterm): Provide GNUstep Base/GUI versions as > `ns-version-string'. > > > --- nsterm.m 21 окт 2008 15:50:42 +0300 1.32 > +++ nsterm.m 22 окт 2008 13:17:21 +0300 > @@ -6382,7 +6382,22 @@ > /* TODO: try to move this back into lisp, ns-win.el loaded too late > right now */ > { > - Lisp_Object args[3] = { intern ("ns-version-string"), > build_string ("9.0"), > +#ifdef NS_IMPL_GNUSTEP > + char gnustep_version[40]; > + snprintf (gnustep_version, sizeof (gnustep_version), > + "(GNUstep Base %u.%u.%u, GUI %u.%u.%u)", > + GNUSTEP_BASE_MAJOR_VERSION, GNUSTEP_BASE_MINOR_VERSION, > + GNUSTEP_BASE_SUBMINOR_VERSION, > + GNUSTEP_GUI_MAJOR_VERSION, GNUSTEP_GUI_MINOR_VERSION, > + GNUSTEP_GUI_SUBMINOR_VERSION); > +#endif > + Lisp_Object args[3] = { intern ("ns-version-string"), > +#ifdef NS_IMPL_GNUSTEP > + build_string (gnustep_version), > +#else > + /* TODO: Something appropriate for Mac OS X. */ > + build_string ("9.0"), > +#endif > build_string ("NS Window system port version > number.") }; > Fdefconst (Flist (3, args)); > } ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-22 10:53 ` Yavor Doganov 2008-10-22 12:29 ` Adrian Robert @ 2008-10-22 13:14 ` Adrian Robert 2008-10-22 17:05 ` Glenn Morris ` (2 more replies) 1 sibling, 3 replies; 22+ messages in thread From: Adrian Robert @ 2008-10-22 13:14 UTC (permalink / raw) To: Yavor Doganov; +Cc: 1171, Stefan Monnier > If there is a meaningful version number for the external GNUstep/Mac > components (analogous to gtk-version-string) against which Emacs was > built, that could also be printed. My complaint is indeed about the > hard-coded "0.9". OK, I've changed it to output a version number determined compile-time from the toolkit, currently one of: gnustep-gui-### apple-appkit-### Yavor, if you decide it's better to report the GNUstep base version also, you can use NSFoundationVersionNumber for OS X. There are four other files where I replaced 9.0 with 23.0.60 or variants of it. Eventually it would be nice to do this automatically with autoconf. In this case it is important NOT to include the extra .# build number that emacs' build system generates. This, by itself, *should* be used for the CFBundleVersion in the Cocoa Info.plist however. nextstep/Cocoa/Emacs.base/Contents/Info.plist nextstep/Cocoa/Emacs.base/Contents/Resources/English.lproj/ InfoPlist.strings nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop nextstep/GNUstep/Emacs.base/Resources/Info-gnustep.plist ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-22 13:14 ` Adrian Robert @ 2008-10-22 17:05 ` Glenn Morris 2008-10-22 21:11 ` Yavor Doganov 2008-10-23 0:48 ` Glenn Morris 2 siblings, 0 replies; 22+ messages in thread From: Glenn Morris @ 2008-10-22 17:05 UTC (permalink / raw) To: Adrian Robert; +Cc: Yavor Doganov, 1171, Stefan Monnier Adrian Robert wrote: > There are four other files where I replaced 9.0 with 23.0.60 or > variants of it. Eventually it would be nice to do this automatically > with autoconf. M-x set-version from admin/admin.el does this kind of thing. I can add entries for the places you just added at some point. > In this case it is important NOT to include the extra .# build > number that emacs' build system generates. This, by itself, *should* > be used for the CFBundleVersion in the Cocoa Info.plist however. > > nextstep/Cocoa/Emacs.base/Contents/Info.plist > nextstep/Cocoa/Emacs.base/Contents/Resources/English.lproj/ > InfoPlist.strings > nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop > nextstep/GNUstep/Emacs.base/Resources/Info-gnustep.plist ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-22 13:14 ` Adrian Robert 2008-10-22 17:05 ` Glenn Morris @ 2008-10-22 21:11 ` Yavor Doganov 2008-10-22 22:43 ` Adrian Robert 2008-10-23 1:02 ` bug#1171: #1171 - ns-version-string - Emacs bug report logs Glenn Morris 2008-10-23 0:48 ` Glenn Morris 2 siblings, 2 replies; 22+ messages in thread From: Yavor Doganov @ 2008-10-22 21:11 UTC (permalink / raw) To: Adrian Robert; +Cc: Yavor Doganov, 1171, Stefan Monnier Adrian Robert wrote: > > OK, I've changed it to output a version number determined > compile-time from the toolkit Thanks, it looks very good and works fine on GNUstep. However, there seems to be something inconsistent (unrelated to your changes): In GNU Emacs 23.0.60 (i686-pc-linux-gnu, NS gnustep-gui-0.12.0) of 2008-10-22 on gana.yavor.doganov.org Windowing system distributor `GNU', version 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.50.46.48 On GNU and Unix-like systems GNUstep uses X, so I find this very strange and of course not informative at all. I haven't checked why `x-server-version' is so bizarre in this case, but probably you know already. > Yavor, if you decide Well, I can't decide anything since I'm not an Emacs developer ;-) > it's better to report the GNUstep base version > also, you can use NSFoundationVersionNumber for OS X. GNUstep Base is fairly stable and complete, and I guess so is Apple's FoundationKit (which is the main reason why gnustep-base is in such a shape, of course). I guess the reasoning to include it in `emacs-version' is if it helps with bug reports. Although there were some very nasty bugs in -base (even recently), it is more or less mature. Time will tell, I think. > nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop IMHO this is entirely useless for GNUstep, because: 1) Typically, GNUstep users do not use freedesktop.org-aware environments such as GNOME/KDE/Xfce. 2) Even in the rare cases when they do, the .desktop files must be in $(datadir)/applications (or ~/.local/share/applications) in order to be parsed, loaded and to show up in the menus. 3) The file is invalid (this can be fixed, certainly, but it is a general problem with all standard GNUstep apps where the pl2link tool generates broken .desktop files and puts them in the wrong place). ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-22 21:11 ` Yavor Doganov @ 2008-10-22 22:43 ` Adrian Robert 2008-10-22 23:20 ` Yavor Doganov 2008-10-23 1:16 ` Stefan Monnier 2008-10-23 1:02 ` bug#1171: #1171 - ns-version-string - Emacs bug report logs Glenn Morris 1 sibling, 2 replies; 22+ messages in thread From: Adrian Robert @ 2008-10-22 22:43 UTC (permalink / raw) To: Yavor Doganov; +Cc: 1171 On Oct 22, 2008, at 5:11 PM, Yavor Doganov wrote: > Adrian Robert wrote: >> >> OK, I've changed it to output a version number determined >> compile-time from the toolkit > > Thanks, it looks very good and works fine on GNUstep. However, there > seems to be something inconsistent (unrelated to your changes): > > In GNU Emacs 23.0.60 (i686-pc-linux-gnu, NS gnustep-gui-0.12.0) > of 2008-10-22 on gana.yavor.doganov.org > Windowing system distributor `GNU', version > 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.50.46.48 How do you generate this output? And do you know what code is responsible? > On GNU and Unix-like systems GNUstep uses X, so I find this very > strange and of course not informative at all. I haven't checked why > `x-server-version' is so bizarre in this case, but probably you know > already. x-server-version should be returning identical to ns-version-string ("gnustep-gui-0.12.0" in this case), which it does here. (Don't be fooled by the name of the function, it does not refer to X11.) If not it is a weird bug. If you could put a println in ns_appkit_version() in nsfns.m and see if it IS indeed being called and if it IS generating that weird string, it would help track it down. >> nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop > > IMHO this is entirely useless for GNUstep, because: > > 1) Typically, GNUstep users do not use freedesktop.org-aware > environments such as GNOME/KDE/Xfce. > 2) Even in the rare cases when they do, the .desktop files must be in > $(datadir)/applications (or ~/.local/share/applications) in order > to be parsed, loaded and to show up in the menus. > 3) The file is invalid (this can be fixed, certainly, but it is a > general problem with all standard GNUstep apps where the pl2link > tool generates broken .desktop files and puts them in the wrong > place). OK, I'll think about dropping the file. thanks, Adrian ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-22 22:43 ` Adrian Robert @ 2008-10-22 23:20 ` Yavor Doganov 2008-10-23 1:16 ` Stefan Monnier 1 sibling, 0 replies; 22+ messages in thread From: Yavor Doganov @ 2008-10-22 23:20 UTC (permalink / raw) To: Adrian Robert; +Cc: Yavor Doganov, 1171 Adrian Robert wrote: > > > Windowing system distributor `GNU', version > > 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.50.46.48 > > How do you generate this output? With M-x report-emacs-bug -- I thought the whole point of this discussion/bug was inluding useful information in initial bug reports, without the necessity to ask the bug reporter about additional details. Anyway, I don't have strong feelings about this -- reporting the gnustep-gui version is good enough. > And do you know what code is responsible? It's in lisp/mai/emacsbug.el. > x-server-version should be returning identical to ns-version-string That's wrong for GNUstep on a GNU/{Linux,Hurd,kFreeBSD} system where presumably the desirable thing is to report the X server version (in fact it would be much better to report the GNUstep backend, or both). Furthermore, although GNUstep has minimal WM support and theoretically Emacs.app can run under plain X (haven't tried that, personally), it is a bit inappropriate to call GNU a "Windowing system distributor". GNUstep provides some primitives, but really relies on X to be available and running. > If you could put a println in ns_appkit_version() in nsfns.m and see > if it IS indeed being called and if it IS generating that weird > string, it would help track it down. Thanks, I'll hopefully do that tomorrow. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-22 22:43 ` Adrian Robert 2008-10-22 23:20 ` Yavor Doganov @ 2008-10-23 1:16 ` Stefan Monnier 2008-11-12 13:34 ` Yavor Doganov 1 sibling, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2008-10-23 1:16 UTC (permalink / raw) To: Adrian Robert; +Cc: Yavor Doganov, 1171 >> 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.50.46.48 > ("gnustep-gui-0.12.0" The first line above seems to list the ascii codes of the second line. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-23 1:16 ` Stefan Monnier @ 2008-11-12 13:34 ` Yavor Doganov 2008-11-12 16:01 ` Stefan Monnier 0 siblings, 1 reply; 22+ messages in thread From: Yavor Doganov @ 2008-11-12 13:34 UTC (permalink / raw) To: Stefan Monnier, 1171, Adrian Robert; +Cc: Yavor Doganov At Wed, 22 Oct 2008 21:16:05 -0400, Stefan Monnier wrote: > > >> 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.50.46.48 > > ("gnustep-gui-0.12.0" > > The first line above seems to list the ascii codes of the second line. Yes, it looks like this this code in emacsbug.el (insert "Windowing system distributor `" (x-server-vendor) "', version " (mapconcat 'number-to-string (x-server-version) ".") "\n") really expects x-server-version to be a number. There are more problems with ns-version-string: 1) It shows the FQDN, which some users might find inappropriate. At least this is not consistent with the other flavors. 2) It doesn't show the host on which Emacs was built, but the host on which it is currently running, e.g. GNU Emacs 23.0.60 (i486-pc-linux-gnu, NS gnustep-gui-0.12.0) of 2008-11-12 on tzotzolana.yavor.doganov.org, modified for gNewSense This was built on a different host and I installed it on tzotzolana as a binary (*.deb) package from an APT repository. 3) The date is also wrong, and shows the current date, not the date Emacs was built. (The actual build date in the above example is 2008-10-27). I guess this is a nasty consequence of CANNOT_DUMP... ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-11-12 13:34 ` Yavor Doganov @ 2008-11-12 16:01 ` Stefan Monnier 2008-11-12 19:11 ` Yavor Doganov 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2008-11-12 16:01 UTC (permalink / raw) To: 1171; +Cc: Yavor Doganov, Adrian Robert > Yes, it looks like this this code in emacsbug.el > (insert "Windowing system distributor `" (x-server-vendor) > "', version " > (mapconcat 'number-to-string (x-server-version) ".") "\n") > really expects x-server-version to be a number. Actually a list of numbers. > There are more problems with ns-version-string: > 1) It shows the FQDN, which some users might find inappropriate. At > least this is not consistent with the other flavors. > 2) It doesn't show the host on which Emacs was built, but the host on > which it is currently running, e.g. > GNU Emacs 23.0.60 (i486-pc-linux-gnu, NS gnustep-gui-0.12.0) > of 2008-11-12 on tzotzolana.yavor.doganov.org, modified for gNewSense > This was built on a different host and I installed it on tzotzolana as > a binary (*.deb) package from an APT repository. > 3) The date is also wrong, and shows the current date, not the date > Emacs was built. (The actual build date in the above example is > 2008-10-27). I guess this is a nasty consequence of CANNOT_DUMP... These all seem to be direct consequences of using CANNOT_DUMP and probably do not manifest under Cocoa. I wouldn't worry too much about it (better fix the underlying problem and get dumping to work for GNUstep). Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-11-12 16:01 ` Stefan Monnier @ 2008-11-12 19:11 ` Yavor Doganov 2008-11-12 19:19 ` Adrian Robert 2008-11-12 19:48 ` bug#1171: #1171 - ns-version-string - Emacs bug report logs Stefan Monnier 0 siblings, 2 replies; 22+ messages in thread From: Yavor Doganov @ 2008-11-12 19:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: Yavor Doganov, Adrian Robert, 1171 Stefan Monnier wrote: > > These all seem to be direct consequences of using CANNOT_DUMP and > probably do not manifest under Cocoa. Yes, as can be observed by the reports of these users. > I wouldn't worry too much about it Sure, the only possible problem is the confusion in bug reports that the wrong date may cause. But if Emacs developers remember that it's bogus, there is no problem. > (better fix the underlying problem and get dumping to work for > GNUstep). Does this require changes in the GNU ObjC runtime, GNUstep, or Emacs? Or a combination of these? ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-11-12 19:11 ` Yavor Doganov @ 2008-11-12 19:19 ` Adrian Robert 2008-11-12 19:50 ` Emacs cannot dump on GNUstep Yavor Doganov 2008-11-12 19:48 ` bug#1171: #1171 - ns-version-string - Emacs bug report logs Stefan Monnier 1 sibling, 1 reply; 22+ messages in thread From: Adrian Robert @ 2008-11-12 19:19 UTC (permalink / raw) To: Yavor Doganov; +Cc: 1171 On Nov 12, 2008, at 2:11 PM, Yavor Doganov wrote: > Stefan Monnier wrote: >> >> (better fix the underlying problem and get dumping to work for >> GNUstep). > > Does this require changes in the GNU ObjC runtime, GNUstep, or Emacs? > Or a combination of these? Unknown, hopefully just the last one, or the last two. If someone (you?) who is compiling / testing on GNUstep could get together a description of the failure when dumping is attempted (probably a stack trace of the crash when the dumped emacs is run), and post that to gnustep-dev@gnu.org , that would be a good start to learning more / starting on a solution. Adrian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Emacs cannot dump on GNUstep 2008-11-12 19:19 ` Adrian Robert @ 2008-11-12 19:50 ` Yavor Doganov 2008-11-12 20:27 ` Adrian Robert 0 siblings, 1 reply; 22+ messages in thread From: Yavor Doganov @ 2008-11-12 19:50 UTC (permalink / raw) To: Adrian Robert; +Cc: Yavor Doganov, emacs-devel, Stefan Monnier, gnustep-dev [CC-ing emacs-devel instead of bug #1171, as this is a general problem.] At Wed, 12 Nov 2008 14:19:10 -0500, Adrian Robert wrote: > On Nov 12, 2008, at 2:11 PM, Yavor Doganov wrote: > > Stefan Monnier wrote: > >> > >> (better fix the underlying problem and get dumping to work for > >> GNUstep). > > > > Does this require changes in the GNU ObjC runtime, GNUstep, or Emacs? > > Or a combination of these? > > Unknown, hopefully just the last one, or the last two. If someone > (you?) who is compiling / testing on GNUstep could get together a > description of the failure when dumping is attempted (probably a > stack trace of the crash when the dumped emacs is run), and post > that to gnustep-dev@gnu.org , that would be a good start to learning > more / starting on a solution. OK, I did a fresh checkout, and only commented this in configure.in: /* Sadly for now, GNUstep dump does not work. */ #ifdef NS_IMPL_GNUSTEP #define CANNOT_DUMP #endif On a GNU/Linux system with GNU libc 2.7 GCC 4.3.2 GNUstep Base 1.16.1 (built against libffi 3.0.6) GNUstep GUI 0.14.0 I get the following failure in `make bootstrap': ... Loading /home/yavor/scratch/emacs/lisp/vc-hooks.el (source)... Loading /home/yavor/scratch/emacs/lisp/ediff-hook.el (source)... Loading /home/yavor/scratch/emacs/lisp/tooltip.el (source)... ((299647 . 7630) (14458 . 2) (661 . 158) 2099780 1312349 (108 . 2) (23 . 19) (32049 . 11862)) Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name emacs 73426 pure bytes used mv -f emacs bootstrap-emacs cd ../lisp; make -w compile-first EMACS=../src/bootstrap-emacs make[3]: Entering directory `/home/yavor/scratch/emacs/lisp' Compiling /home/yavor/scratch/emacs/lisp/emacs-lisp/bytecomp.el make[3]: *** [/home/yavor/scratch/emacs/lisp/emacs-lisp/bytecomp.elc] Segmentation fault make[3]: Leaving directory `/home/yavor/scratch/emacs/lisp' make[2]: *** [bootstrap-emacs] Error 2 make[2]: Leaving directory `/home/yavor/scratch/emacs/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/home/yavor/scratch/emacs' make: *** [bootstrap] Error 2 gdb src/bootstrap-emacs (gdb) cd lisp Working directory /home/yavor/scratch/emacs/lisp. (gdb) r -f batch-byte-compile emacs-lisp/bytecomp.el Starting program: /home/yavor/scratch/emacs/src/bootstrap-emacs -f batch-byte-compile emacs-lisp/bytecomp.el [Thread debugging using libthread_db enabled] [New Thread 0xb6f836c0 (LWP 24785)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6f836c0 (LWP 24785)] 0xb77a00ae in objc_hash_string (cache=0x8810428, key=0x6004e) at /scratch/packages/gcc/4.3/gcc-4.3-4.3.2/src/libobjc/objc/hash.h:181 181 /scratch/packages/gcc/4.3/gcc-4.3-4.3.2/src/libobjc/objc/hash.h: No such file or directory. in /scratch/packages/gcc/4.3/gcc-4.3-4.3.2/src/libobjc/objc/hash.h #0 0xb77a00ae in objc_hash_string (cache=0x8810428, key=0x6004e) at /scratch/packages/gcc/4.3/gcc-4.3-4.3.2/src/libobjc/objc/hash.h:181 ret = 0 ctr = 0 ckey = 0x6004e <Address 0x6004e out of bounds> #1 0xb779caba in objc_hash_value_for_key (cache=0x8810428, key=0x6004e) at /scratch/packages/gcc/4.3/gcc-4.3-4.3.2/src/libobjc/hash.c:251 node = <value optimized out> retval = <value optimized out> #2 0xb77a03b0 in __sel_register_typed_name ( name=0x6004e <Address 0x6004e out of bounds>, types=0x0, orig=0x83a1880, is_const=1 '\001') at /scratch/packages/gcc/4.3/gcc-4.3-4.3.2/src/libobjc/selector.c:371 j = <value optimized out> i = 1 l = <value optimized out> #3 0xb779d89c in __objc_exec_class (module=0x83a1d98) at /scratch/packages/gcc/4.3/gcc-4.3-4.3.2/src/libobjc/init.c:563 symtab = (Symtab_t) 0x83a1868 cell = <value optimized out> selectors = (SEL) 0x83a1880 i = <value optimized out> previous_constructors = 1 '\001' ---Type <return> to continue, or q <return> to quit--- unclaimed_categories = (struct objc_list *) 0x0 __PRETTY_FUNCTION__ = "__objc_exec_class" #4 0x0822d9b0 in __objc_gnu_init () at nsfont.m:1490 No locals. #5 0x0823bbcd in __do_global_ctors_aux () No locals. #6 0x0808e594 in _init () No locals. #7 0x0823bb69 in __libc_csu_init () No locals. #8 0xb75793ec in __libc_start_main () from /lib/i686/cmov/libc.so.6 No symbol table info available. #9 0x0808f781 in _start () No locals. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Emacs cannot dump on GNUstep 2008-11-12 19:50 ` Emacs cannot dump on GNUstep Yavor Doganov @ 2008-11-12 20:27 ` Adrian Robert 0 siblings, 0 replies; 22+ messages in thread From: Adrian Robert @ 2008-11-12 20:27 UTC (permalink / raw) To: Yavor Doganov; +Cc: emacs-devel, Stefan Monnier, gnustep-dev Hi, The previous email is about this problem of Emacs.app not working when dumped under GNUstep. Since I cannot work on this myself at the moment (and failed when I *did* put time into it before), let me provide the background of what I know. What happens is this: emacs loads into memory, then performs a bunch of initialization (mainly reading/interpreting elisp files), then dumps its in-memory executable +data image out to disk. In the future, this becomes the new executable, the idea being that you then are up and running without having to perform the initialization. Something in this causes a failure under GNUstep (trace below). I'm not sure if it's a problem with the emacs dump code or with initialization in the GNUstep runtime, but I think there is some more that can be tried on the emacs side codewise, though it would be best done by someone acquainted with GNUstep memory handling. The thing to look at is the difference between unexmacosx.c and, e.g., unexelf.c. It seems that some special handling for memory allocation may be needed. In unexmacosx, we read in the comments: > The Mac OS X implementation of unexec makes use of Darwin's `zone' > memory allocator. All calls to malloc, realloc, and free in Emacs > are redirected to unexec_malloc, unexec_realloc, and unexec_free in > this file. When temacs is run, all memory requests are handled in > the zone EmacsZone. The Darwin memory allocator library calls > maintain the data structures to manage this zone. Dumping writes > its contents to data segments of the executable file. When emacs > is run, the loader recreates the contents of the zone in memory. > However since the initialization routine of the zone memory > allocator is run again, this `zone' can no longer be used as a > heap. That is why emacs uses the ordinary malloc system call to > allocate memory. Also, when a block of memory needs to be > reallocated and the new size is larger than the old one, a new > block must be obtained by malloc and the old contents copied to > it. It is possible that adding this sort of logic to unexelf will solve the problem. Note there are also some #defines in darwin.h that would need to be replicated in gnu-linux.h or whatever system is being compiled on. Because emacs plays a number of games with malloc on different systems (search for "Doug Leah" in the code and configure scripts) there may be more to be done than straight copy-paste. If there is still a failure after this is tried, there may be a gnu- apple difference in the runtime or how the foundation library initializes. But we can't be sure about this until unexelf under GNUstep does everything that unexmacosx does. -Adrian ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-11-12 19:11 ` Yavor Doganov 2008-11-12 19:19 ` Adrian Robert @ 2008-11-12 19:48 ` Stefan Monnier 2008-12-11 23:46 ` bug#1171: ns-version-string Glenn Morris 1 sibling, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2008-11-12 19:48 UTC (permalink / raw) To: 1171; +Cc: Yavor Doganov, Adrian Robert >> I wouldn't worry too much about it > Sure, the only possible problem is the confusion in bug reports that > the wrong date may cause. But if Emacs developers remember that it's > bogus, there is no problem. Well, it is not completely irrelelvant, but fixing it is probably more trouble than will be incurred because of confusion. >> (better fix the underlying problem and get dumping to work for GNUstep). > Does this require changes in the GNU ObjC runtime, GNUstep, or Emacs? > Or a combination of these? It should only require changes in Emacs, normally. But the main thing it requires is someone to attack the problem. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: ns-version-string 2008-11-12 19:48 ` bug#1171: #1171 - ns-version-string - Emacs bug report logs Stefan Monnier @ 2008-12-11 23:46 ` Glenn Morris 2008-12-31 15:03 ` Adrian Robert 0 siblings, 1 reply; 22+ messages in thread From: Glenn Morris @ 2008-12-11 23:46 UTC (permalink / raw) To: 1171; +Cc: Adrian Robert Please consider fixing the NS implementation of x-server-version to return a list of three integers, as it is documented to do (xfns.c, w32fns.c). It's getting a bit ridiculous seeing all the Emacs.App bug reports with Windowing system distributor `Apple', version 97.112.112.108.101.45.97.112.112.107.105.116.45.57.52.57.46.51.53 configured using `configure '--with-ns'' (Again, this comes from M-x report-emacs-bug.) Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: ns-version-string 2008-12-11 23:46 ` bug#1171: ns-version-string Glenn Morris @ 2008-12-31 15:03 ` Adrian Robert 0 siblings, 0 replies; 22+ messages in thread From: Adrian Robert @ 2008-12-31 15:03 UTC (permalink / raw) To: Glenn Morris; +Cc: 1171 On Dec 12, 2008, at 1:46 AM, Glenn Morris wrote: > > Please consider fixing the NS implementation of x-server-version to > return a list of three integers, as it is documented to do (xfns.c, > w32fns.c). Done. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-22 21:11 ` Yavor Doganov 2008-10-22 22:43 ` Adrian Robert @ 2008-10-23 1:02 ` Glenn Morris 1 sibling, 0 replies; 22+ messages in thread From: Glenn Morris @ 2008-10-23 1:02 UTC (permalink / raw) To: Adrian Robert; +Cc: Yavor Doganov, 1171 Yavor Doganov wrote: >> nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop > > IMHO this is entirely useless for GNUstep, because: [...] > 2) Even in the rare cases when they do, the .desktop files must be in > $(datadir)/applications (or ~/.local/share/applications) in order > to be parsed, loaded and to show up in the menus. The top-level Makefile.in has a rule (install-etc) which installs the file etc/emacs.desktop in the right place. This could be copied/adapted for the GNUstep version. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#1171: #1171 - ns-version-string - Emacs bug report logs 2008-10-22 13:14 ` Adrian Robert 2008-10-22 17:05 ` Glenn Morris 2008-10-22 21:11 ` Yavor Doganov @ 2008-10-23 0:48 ` Glenn Morris 2 siblings, 0 replies; 22+ messages in thread From: Glenn Morris @ 2008-10-23 0:48 UTC (permalink / raw) To: Adrian Robert; +Cc: Yavor Doganov, 1171, Stefan Monnier Adrian Robert wrote: > In this case it is important NOT to include the extra .# build > number that emacs' build system generates. This, by itself, *should* > be used for the CFBundleVersion in the Cocoa Info.plist however. You mean in nextstep/Cocoa/Emacs.base/Contents/Info.plist, the CFBundleVersion string that is currently hard-coded at "9.0" should be replaced by the Emacs build number ("1", "2", ...), and so get changed every time Emacs gets rebuilt? I don't see how you would do this. Actually, this number doesn't even seem to exist in the nextstep port, since it does not get dumped. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2008-12-31 15:03 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-10-21 13:31 bug#1171: #1171 - ns-version-string - Emacs bug report logs Adrian Robert 2008-10-21 15:52 ` Stefan Monnier 2008-10-21 22:37 ` Glenn Morris 2008-10-22 10:53 ` Yavor Doganov 2008-10-22 12:29 ` Adrian Robert 2008-10-22 13:14 ` Adrian Robert 2008-10-22 17:05 ` Glenn Morris 2008-10-22 21:11 ` Yavor Doganov 2008-10-22 22:43 ` Adrian Robert 2008-10-22 23:20 ` Yavor Doganov 2008-10-23 1:16 ` Stefan Monnier 2008-11-12 13:34 ` Yavor Doganov 2008-11-12 16:01 ` Stefan Monnier 2008-11-12 19:11 ` Yavor Doganov 2008-11-12 19:19 ` Adrian Robert 2008-11-12 19:50 ` Emacs cannot dump on GNUstep Yavor Doganov 2008-11-12 20:27 ` Adrian Robert 2008-11-12 19:48 ` bug#1171: #1171 - ns-version-string - Emacs bug report logs Stefan Monnier 2008-12-11 23:46 ` bug#1171: ns-version-string Glenn Morris 2008-12-31 15:03 ` Adrian Robert 2008-10-23 1:02 ` bug#1171: #1171 - ns-version-string - Emacs bug report logs Glenn Morris 2008-10-23 0:48 ` Glenn Morris
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.