On Sat, 27 Nov 2010, Bram Moolenaar wrote:
Hisashi T Fujinaka wrote:
I think this worked for me, because there's something odd in 10.6 where
gvim crashes. The crash log says
Application Specific Information:
abort() called
USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
Anything that uses CoreFoundation isn't supposed just to fork, and the
vim GUI in fink uses CoreFoundation via gtk+2.
So I applied this patch (which I hope is right):
diff -Naur vim-7.3.069.orig/src/gui.c vim-7.3.069/src/gui.c
--- vim-7.3.069.orig/src/gui.c 2010-11-25 14:56:25.000000000 -0800
+++ vim-7.3.069/src/gui.c 2010-11-25 14:58:35.000000000 -0800
@@ -59,7 +59,7 @@
gui_start()
{
char_u *old_term;
-#if defined(UNIX) && !defined(__BEOS__) && !defined(MACOS_X)
+#if defined(UNIX) && !defined(__BEOS__) && !defined(MACOS_X) &&
!defined(__APPLE__)
# define MAY_FORK
int dofork = TRUE;
#endif
I wonder why __APPLE__ is defined while MACOS_X isn't. Perhaps the
solution would be to define MACOS_X ? I don't know what version you are
building.
7.3.69? It's like I said before, I'm building the x version. It doesn't
build things like os_macosx.m and if it tries the build dies.
Ah, you are building the Unix version on Mac. Then MACOS_X is not
defined (confusing that building with X on Mac doesn't define this).
I see __APPLE__ is also used in os_unix.c, thus it should be OK.
However, I know others have been building Vim with GTK on Mac. Why
didn't they run into this problem? Perhaps we need another condition
that more specifically detects the situation where fork doesn't work.
It's been building fine, but gvim hasn't really worked since 7.2.446, at
least according to the regression I just did. vim in a console, which is
what I usually use, works fine.
--
Hisashi T Fujinaka - [email protected]
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
