Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On 15 Jul 2008, at 19:52, Adrian Robert wrote:
>
> easy-mmode IS needed, right now.  If there was a change in
> the last few hours for that file to start requiring 'cl, I guess that
> would explain it.

That's doesn't appear to be the case.

As for easy-mmode, it actually uses `eval-when-compile', so it  
shouldn't really be an issue.

I'm not sure where is error comes from. cc'ing emacs-devel.

- D

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Glenn Morris]

David Reitter wrote:

> I'm not sure where is error comes from. cc'ing emacs-devel.

I think easymenu, easy-mmode, ns-win need to be added to
SOME_MACHINE_LISP in src/Makefile.in.

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

On 15 Jul 2008, at 21:09, Glenn Morris wrote:

> David Reitter wrote:
>
>> I'm not sure where is error comes from. cc'ing emacs-devel.
>
> I think easymenu, easy-mmode, ns-win need to be added to
> SOME_MACHINE_LISP in src/Makefile.in.

well, that fixed it.  thanks!
Checking the change below in (soon, since it's based on your advice).

- David



*** Makefile.in	15 Jul 2008 14:35:28 -0400	1.410
--- Makefile.in	16 Jul 2008 01:17:08 -0400	
***************
*** 897,903 ****
     ../lisp/international/codepage.elc \
     ../lisp/international/fontset.elc \
     ../lisp/mouse.elc \
!   ../lisp/term/x-win.elc

   /* Construct full set of libraries to be linked.
      Note that SunOS needs -lm to come before -lc; otherwise, you get
--- 897,907 ----
     ../lisp/international/codepage.elc \
     ../lisp/international/fontset.elc \
     ../lisp/mouse.elc \
!   ../lisp/term/x-win.elc \
!   ../lisp/term/ns-win.elc \
!   ../lisp/emacs-lisp/easy-mmode.elc \
!   ../lisp/ns-carbon-compat.elc \
!   ../lisp/emacs-lisp/easy-menu.elc

   /* Construct full set of libraries to be linked.
      Note that SunOS needs -lm to come before -lc; otherwise, you get


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[CHENG Gao]

*On Wed, 16 Jul 2008 01:22:49 -0400
* Also sprach David Reitter <david.reitter@gmail.com>:

> On 15 Jul 2008, at 21:09, Glenn Morris wrote:
>
>> David Reitter wrote:
>>
>>> I'm not sure where is error comes from. cc'ing emacs-devel.
>>
>> I think easymenu, easy-mmode, ns-win need to be added to
>> SOME_MACHINE_LISP in src/Makefile.in.
>
> well, that fixed it.  thanks!
> Checking the change below in (soon, since it's based on your advice).

Thanks! Now I had a sucessful build. (MacOSX 10.5.4)

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Adrian Robert]

On Jul 16, 2008, at 1:22 AM, David Reitter wrote:

> On 15 Jul 2008, at 21:09, Glenn Morris wrote:
>
>> David Reitter wrote:
>>
>>> I'm not sure where is error comes from. cc'ing emacs-devel.
>>
>> I think easymenu, easy-mmode, ns-win need to be added to
>> SOME_MACHINE_LISP in src/Makefile.in.
>
> well, that fixed it.  thanks!

> !   ../lisp/emacs-lisp/easy-mmode.elc \

Could you double-check if this portion is still needed (since I took  
out the load of easy-mmode from loadup.el last night)?  I wasn't able  
to replicate the error before so I can't check it.

thanks,
Adrian

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Stefan Monnier]

>> easy-mmode IS needed, right now.

That seems wrong.  Can you explain why you think it's needed?


        Stefan


PS: Furthermore, it was not mentioned in the ChangeLog:

	* loadup.el: Load ns-win.el if ns-windowing is active.

   (if (featurep 'ns-windowing)
       (progn
         (load "emacs-lisp/easymenu")  ;; for platform-related menu adjustments
         (load "emacs-lisp/easy-mmode")
         (load "term/ns-win")))

You need to be more careful with your ChangeLog entries.

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Adrian Robert]

On Jul 15, 2008, at 9:49 PM, Stefan Monnier wrote:

>>> easy-mmode IS needed, right now.
>
> That seems wrong.  Can you explain why you think it's needed?

OK, it seems it's NOT needed.  I was confused since it looked like  
define-minor-mode was defined in easy-mmode.  Hmm..  Anyway, my bad.   
Removed in CVS.

HOWEVER, others are still getting problems with define-minor-mode  
calls in ns-win where I am not.  It would be interesting to know why  
ns-win is special, since define-minor-mode is called in many other  
lisp files that are loaded from loadup.el.


> PS: Furthermore, it was not mentioned in the ChangeLog:
>
> 	* loadup.el: Load ns-win.el if ns-windowing is active.
>
> ...
> You need to be more careful with your ChangeLog entries.

I was trying to be brief.  ;-)

Seriously, I wasn't sure what balance to strike between detail and not  
writing a novel, but I'll go back and edit whatever desired.

Regarding Glenn's suggestion of adding ns-win.el and friends to  
SOME_MACHINE_LISP, it appears that the only GUI that does this is X.   
Should all three of w32-win, mac-win, and ns-win be added?

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Cezar Halmagean]

I still get this error compiling cvs emacs :

Undefined symbols:
   "_tgetflag", referenced from:
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
   "_tgetent", referenced from:
       _init_tty in term.o
   "_tgetnum", referenced from:
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
   "_BC", referenced from:
       _BC$non_lazy_ptr in cm.o
   "_PC", referenced from:
       _PC$non_lazy_ptr in term.o
   "_tgetstr", referenced from:
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _term_get_fkeys_1 in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
   "_UP", referenced from:
       _UP$non_lazy_ptr in cm.o
   "_tgoto", referenced from:
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmgoto in cm.o
       _cmgoto in cm.o
   "_tputs", referenced from:
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _cmcostinit in cm.o
       _calccost in cm.o
       _calccost in cm.o
       _calccost in cm.o
       _cmgoto in cm.o
       _cmgoto in cm.o
       _cmgoto in cm.o
       _cmgoto in cm.o
       _cmgoto in cm.o
       _tty_ring_bell in term.o
       _tty_set_terminal_modes in term.o
       _tty_set_terminal_modes in term.o
       _tty_set_terminal_modes in term.o
       _tty_set_terminal_modes in term.o
       _tty_reset_terminal_modes in term.o
       _tty_reset_terminal_modes in term.o
       _tty_reset_terminal_modes in term.o
       _tty_reset_terminal_modes in term.o
       _tty_set_scroll_region in term.o
       _tty_turn_on_insert in term.o
       _tty_turn_off_insert in term.o
       _tty_turn_off_highlight in term.o
       _tty_turn_on_highlight in term.o
       _tty_hide_cursor in term.o
       _tty_show_cursor in term.o
       _tty_show_cursor in term.o
       _tty_clear_to_end in term.o
       _tty_clear_frame in term.o
       _tty_clear_end_of_line in term.o
       _tty_insert_glyphs in term.o
       _tty_insert_glyphs in term.o
       _tty_insert_glyphs in term.o
       _tty_insert_glyphs in term.o
       _tty_delete_glyphs in term.o
       _tty_delete_glyphs in term.o
       _tty_delete_glyphs in term.o
       _tty_delete_glyphs in term.o
       _tty_ins_del_lines in term.o
       _tty_ins_del_lines in term.o
       _tty_ins_del_lines in term.o
       _string_cost in term.o
       _string_cost_one_line in term.o
       _per_line_cost in term.o
       _per_line_cost in term.o
       _turn_on_face in term.o
       _turn_on_face in term.o
       _turn_on_face in term.o
       _turn_on_face in term.o
       _turn_on_face in term.o
       _turn_on_face in term.o
       _turn_on_face in term.o
       _turn_off_face in term.o
       _turn_off_face in term.o
       _turn_off_face in term.o
       _turn_off_face in term.o
       _turn_off_face in term.o
       _reset_sys_modes in sysdep.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [temacs] Error 1
make: *** [src] Error 2
*** Compilation failed. ***
Please examine the above output to determine what went wrong,
edit the configure options in this script (\'compile\') to fix it, and  
rerun.


Cezar

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Peter Dyballa]

Am 16.07.2008 um 05:09 schrieb Cezar Halmagean:

> I still get this error compiling cvs emacs :

Libncurses is missing. _BC, _PC, _UP are typical TERMCAP support.

--
Greetings

   Pete

Engineer: a mechanism for converting caffeine into designs

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[CHENG Gao]

*On Tue, 15 Jul 2008 23:01:18 -0400
* Also sprach Adrian Robert <adrian.b.robert@gmail.com>:

> On Jul 15, 2008, at 9:49 PM, Stefan Monnier wrote:
>
>>>> easy-mmode IS needed, right now.
>>
>> That seems wrong.  Can you explain why you think it's needed?
>
> OK, it seems it's NOT needed.  I was confused since it looked like
> define-minor-mode was defined in easy-mmode.  Hmm..  Anyway, my bad.
> Removed in CVS.
>
> HOWEVER, others are still getting problems with define-minor-mode calls
> in ns-win where I am not.  It would be interesting to know why  ns-win
> is special, since define-minor-mode is called in many other  lisp files
> that are loaded from loadup.el.

I tried to build it by:

autoconf
./configure --with-ns --without-x --enable-ns-app --prefix=/usr/local
--without-freetype
make bootstrap

and I got error message as:

,----
| Loading emacs-lisp/easymenu.el (source)...
| Loading term/ns-win.el (source)...
| Loading ns-carbon-compat.el (source)...
| Attempt to autoload define-minor-mode while preparing to dump
| make[2]: *** [emacs] Error 255
| make[1]: *** [src] Error 2
| make: *** [bootstrap] Error 2
`----

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Seiji Zenitani]

I succeed to compile the Cocoa port
when I commented out the following lines.

  * (load "emacs-lisp/easy-mmode") in loadup.el
  * Two (define-minor-mode ... things in term/ns-win.el

Some of them causes the problem.
Emacs runs in -nw mode, but
it immediately crashes in ns-windowing environment
due to font-related error.

> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x911e903c
> 0x001fd63b in nsfont_escape_name (name=0x911e9034 "Hiragino Kaku  
> Gothic ProN") at nsfont.m:74
> 74	      name[i] = '_';


Seiji

On 2008/07/15, at 20:23, David Reitter wrote:

> On 15 Jul 2008, at 19:52, Adrian Robert wrote:
>>
>> easy-mmode IS needed, right now.  If there was a change in
>> the last few hours for that file to start requiring 'cl, I guess that
>> would explain it.
>
> That's doesn't appear to be the case.
>
> As for easy-mmode, it actually uses `eval-when-compile', so it  
> shouldn't really be an issue.
>
> I'm not sure where is error comes from. cc'ing emacs-devel.
>
> -  
> D 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> Emacs-app-dev- mailing list
> Emacs-app-dev-@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emacs-app-dev-

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Miles Bader]

I'm attempting to build Emacs.app using gnustep (not sure how to tell
the version, it's whatever's in debian unstable).

Doing ( cd nextstep; ./compile --shared-lisp=/usr/local )
things succeed until it temacs dies with the following error:

   ln temacs bootstrap-emacs
   cd ../lisp; make -w compile-first EMACS=../src/bootstrap-emacs
   make[2]: ディレクトリ `/usr/local/src/emacs/gnustep/lisp' に入ります
   Compiling /usr/local/src/emacs/gnustep/lisp/emacs-lisp/bytecomp.el
   2008-07-16 02:55:20.118 bootstrap-emacs[4619] Unknown time zone name `JST'.
   2008-07-16 02:55:20.118 bootstrap-emacs[4619] Using time zone with absolute offset 0.
   2008-07-16 02:55:20.001 bootstrap-emacs[4619] autorelease called without pool for object (9c42d00) of class NSMethodSignature in thread <NSThread: 0x9c2ebb8>
   2008-07-16 02:55:20.119 bootstrap-emacs[4619] autorelease called without pool for object (9c5e640) of class GSFFCallInvocation in thread <NSThread: 0x9c2ebb8>
   2008-07-16 02:55:20.120 bootstrap-emacs[4619] autorelease called without pool for object (9c753e0) of class GSCInlineString in thread <NSThread: 0x9c2ebb8>
   2008-07-16 02:55:20.120 bootstrap-emacs[4619] autorelease called without pool for object (9c7c578) of class NSException in thread <NSThread: 0x9c2ebb8>
   2008-07-16 02:55:20.121 bootstrap-emacs[4619] autorelease called without pool for object (9c7bf20) of class GSMutableArray in thread <NSThread: 0x9c2ebb8>
   Fatal error (6)
   make[2]: *** [/usr/local/src/emacs/gnustep/lisp/emacs-lisp/bytecomp.elc] アボートしました
   make[2]: ディレクトリ `/usr/local/src/emacs/gnustep/lisp' から出ます
   make[1]: *** [bootstrap-emacs] エラー 2
   make[1]: ディレクトリ `/usr/local/src/emacs/gnustep/src' から出ます
   make: *** [src] エラー 2
   *** Compilation failed. ***
   Please examine the above output to determine what went wrong,
   edit the configure options in this script (\'compile\') to fix it, and rerun.

Are those "autorelease..." messages fatal errors, or is the abort
something else?

Thanks,

-Miles

-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Miles Bader]

FWIW, here's a little gdb session with stack backtrace... not very
useful looking but...

[It dies even if I just run src/bootstrap-emacs without any arguments]

   (gdb) run
   Starting program: /usr/local/src/emacs/gnustep/src/bootstrap-emacs 
   [Thread debugging using libthread_db enabled]
   [New Thread 0xb6f276c0 (LWP 7329)]
   2008-07-16 06:27:31.900 bootstrap-emacs[7329] Unknown time zone name `JST'.
   2008-07-16 06:27:31.901 bootstrap-emacs[7329] Using time zone with absolute offset 0.
   2008-07-16 06:27:31.892 bootstrap-emacs[7329] autorelease called without pool for object (8a3d590) of class NSMethodSignature in thread <NSThread: 0x8a29460>
   2008-07-16 06:27:31.904 bootstrap-emacs[7329] autorelease called without pool for object (8aa2f48) of class GSFFCallInvocation in thread <NSThread: 0x8a29460>
   2008-07-16 06:27:31.905 bootstrap-emacs[7329] autorelease called without pool for object (8aa9a60) of class GSCInlineString in thread <NSThread: 0x8a29460>
   2008-07-16 06:27:31.905 bootstrap-emacs[7329] autorelease called without pool for object (8a9f520) of class NSException in thread <NSThread: 0x8a29460>
   2008-07-16 06:27:31.906 bootstrap-emacs[7329] autorelease called without pool for object (8a77b00) of class GSMutableArray in thread <NSThread: 0x8a29460>

   Program received signal SIGABRT, Aborted.
   [Switching to Thread 0xb6f276c0 (LWP 7329)]
   0xb7f82424 in __kernel_vsyscall ()

   (gdb) ba
   #0  0xb7ef9424 in __kernel_vsyscall ()
   #1  0xb73fa8f6 in kill () from /lib/i686/cmov/libc.so.6
   #2  0x08166bee in abort () at emacs.c:432
   #3  0xb76d3e8f in objc_exception_throw () from /usr/lib/libobjc.so.2
   #4  0xb7808a28 in ?? () from /usr/lib/libgnustep-base.so.1.16
   #5  0xb7808503 in ?? () from /usr/lib/libgnustep-base.so.1.16
   #6  0xb7808440 in ?? () from /usr/lib/libgnustep-base.so.1.16
   #7  0xb7851f3e in ?? () from /usr/lib/libgnustep-base.so.1.16
   #8  0xb7852111 in ?? () from /usr/lib/libgnustep-base.so.1.16
   #9  0xb790bad1 in ?? () from /usr/lib/libgnustep-base.so.1.16
   #10 0xb70517b5 in __vacall_r () from /usr/lib/libcallback.so.0
   #11 0xb7adf540 in ?? () from /usr/lib/libgnustep-base.so.1.16
   #12 0xbf911454 in ?? ()
   #13 0x00000004 in ?? ()
   #14 0xbf911488 in ?? ()
   #15 0x00000000 in ?? ()

Thanks,

-Miles

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Miles Bader]

BTW, please don't CC messages to closed mailing lists (unless the list
has a functioning moderator system that can accept messages from
non-subscribers -- something which seems very rare these days).

It's annoying to get all the rejection messages, and gives the people
who are reading on the closed list an inaccurate view of the
conversation.

Thanks,

-Miles

-- 
80% of success is just showing up.  --Woody Allen

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Yavor Doganov]

Miles Bader wrote:
> 
> FWIW, here's a little gdb session with stack backtrace... not very
> useful looking but...
> 
> [It dies even if I just run src/bootstrap-emacs without any arguments]

It fails also on gNewSense 2.0 as well with older versions of the
GNUstep (-base 1.14.1, -gui 0.12.0) libraries.

Further debugging (with GNUstep Base built with libffi, as libffcall
munges the backtrace more aggressively) shows that the fault is in
nsterm.m:

void *
ns_alloc_autorelease_pool ()
/* --------------------------------------------------------------------------
     Allocate a pool for temporary objects (callable from C)
   -------------------------------------------------------------------------- */
{
  return [[NSAutoreleasePool alloc] init];
}

This function is called in emacs.c and it appears that this is the
first ObjC function called at initialization.  Maybe there are
necessary compiler/linker flags and options that are omitted for some
reason (deliberate or not); perhaps it is related to -nostdlib and
-lgcc used in Emacs' build system (for reasons I can't fully
understand) or some other oddity.

If it would be of any help, here is how GNUstep Make compiles a random
GNUstep application on GNU/Linux:

gcc Section.m -c \
	      -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -g -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -fgnu-runtime -fconstant-string-class=NSConstantString -I. -I/home/yavor/GNUstep/Library/Headers -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
	       -o obj/Section.o

Link stage:

gcc  -rdynamic      -shared-libgcc -fexceptions -fgnu-runtime -o HelpViewer.app/./HelpViewer \
	./obj/main.o ./obj/mainWindowController.o ./obj/Label.o ./obj/Controller.o ./obj/FigureCell.o ./obj/Legend.o ./obj/HandlerStructureXLP.o ./obj/TextFormatterXLP.o ./obj/BrowserCell.o ./obj/NoteCell.o ./obj/ModNSString.o ./obj/BRCell.o ./obj/Page.o ./obj/Section.o      -L/home/yavor/GNUstep/Library/Libraries -L/usr/local/lib -L/usr/lib     -lgnustep-gui    -lgnustep-base   -lpthread -lobjc   -lm

I tried a dirty workaround by modifying src/Makefile to include the
missing flags, to no avail.

This is, IMVHO, a grave problem caused by miscompilation/linking on
GNU/Linux; but it looks rather obscure to me right now so I am sorry I
can't really help.

It is unfortunate that the Emacs.app developers run primarily Muck OS
and the code was not tested on GNUstep under GNU/Linux.  Anyway, such
failures right after the merge are more or less expected.  I'll dive
into this tomorrow, unless someone fixes the problem.

Nevertheless, it is a great day for all the GNUsteppers who are also
monks in the GNU Emacs Church -- we've been waiting for the Holy Merge
for years.  Thanks to all the people who made it happen, and of course
Adrian for keeping up with Emacs changes through the years.

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS

[Adrian Robert]

Yavor Doganov <yavor <at> gnu.org> writes:

> If it would be of any help, here is how GNUstep Make compiles a random
> GNUstep application on GNU/Linux:

The flags when compiling emacs SHOULD be identical -- if not and
you can patch configure and makefiles to get it right, that's an
important first step.

The other issue I had when getting the first (emacs 20) version
running under GNUstep was getting the right combination with
firstfile, lastfile, etc. on the link line -- and correct
ordering.  And getting rid of the stdlib.  This is "documented"
in src/Makefile.in.

Issues I sometimes messed with when getting successive versions
to work (usually I would spend the 2 weeks to a month / whatever
to get a new version running on the Mac, then a day or two fixing
it up under GNUstep) include GNUstep main() hackery, and GSConfig
inclusion.  Sorry I can't remember more than this.


> It is unfortunate that the Emacs.app developers run primarily Muck OS
> and the code was not tested on GNUstep under GNU/Linux.  Anyway, such
> failures right after the merge are more or less expected.  I'll dive
> into this tomorrow, unless someone fixes the problem.

There are others working on GNUstep and Emacs.app -- see recent
thread on emacs-app-dev- mailing list (with some overflow to
gnustep-discuss):

http://sourceforge.net/mailarchive/forum.php?forum_name=emacs-app-dev-


 
> Nevertheless, it is a great day for all the GNUsteppers who are also
> monks in the GNU Emacs Church -- we've been waiting for the Holy Merge
> for years.  Thanks to all the people who made it happen, and of course
> Adrian for keeping up with Emacs changes through the years.

Not easy... ;-)