PATCH: dynamically load Python on Solaris

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

PATCH: dynamically load Python on Solaris

Danek Duvall-2
I've been wanting to code this up for a while, and almost had it a while
back, but couldn't quite get it working, and put it aside until today.

It's not ready for integration, since it's not at all tied into the
autoconf setup, and requires that you modify src/auto/config.mk to add
-DDYNAMIC_PYTHON to PYTHON_CFLAGS and wrap -lpython2.4 in PYTHON_LIBS with
-zlazyload / -znolazyload, but otherwise it seems to work: python isn't
loaded until the first python command is executed, and (as far as I've been
able to tell) executes python code just fine after that, has("python") is
true, etc.

Comments on the patch itself are appreciated.  Suggestions on how it might
be made to work on Linux are also appreciated, though I don't really have
any means of testing it at the moment.  And help with getting it tied in
with autoconf would be great; I'm not sure how to move forward on that.  If
there are any Python script torture tests I should run, let me know; I'm
not sure what the best python scripts are to play with.

I haven't looked at doing the other interpreters yet, though I'd like to do
that, as well as see if it's possible to dynamically load the GUI.

Thanks for any thoughts,
Danek

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---


--- if_python.c.orig Sat Feb 14 13:53:41 2009
+++ if_python.c Sat Feb 14 19:21:41 2009
@@ -86,9 +86,11 @@
 #endif
 
 #if defined(DYNAMIC_PYTHON) || defined(PROTO)
+#ifdef MSWIN
 # ifndef DYNAMIC_PYTHON
 #  define HINSTANCE long_u /* for generating prototypes */
 # endif
+#endif
 
 /* This makes if_python.c compile without warnings against Python 2.5
  * on Win32 and Win64. */
@@ -215,7 +217,9 @@
 static void (*dll_PyObject_Free)(void*);
 # endif
 
+#ifdef MSWIN
 static HINSTANCE hinstPython = 0; /* Instance of python.dll */
+#endif
 
 /* Imported exception objects */
 static PyObject *imp_PyExc_AttributeError;
@@ -233,11 +237,17 @@
 /*
  * Table of name to function pointer of python.
  */
+#ifdef MSWIN
 # define PYTHON_PROC FARPROC
+# define PYTHON_PROC_STRUCT FARPROC
+#else
+# define PYTHON_PROC void
+# define PYTHON_PROC_STRUCT void *
+#endif
 static struct
 {
     char *name;
-    PYTHON_PROC *ptr;
+    PYTHON_PROC_STRUCT *ptr;
 } python_funcname_table[] =
 {
     {"PyArg_Parse", (PYTHON_PROC*)&dll_PyArg_Parse},
@@ -301,6 +311,7 @@
     {"", NULL},
 };
 
+#ifdef MSWIN
 /*
  * Free python.dll
  */
@@ -358,6 +369,7 @@
 {
     return python_runtime_link_init(DYNAMIC_PYTHON_DLL, verbose) == OK;
 }
+#endif /* MSWIN */
 
 /* Load the standard Python exceptions - don't import the symbols from the
  * DLL, as this can cause errors (importing data symbols is not reliable).
@@ -381,6 +393,58 @@
     Py_XINCREF(imp_PyExc_ValueError);
     Py_XDECREF(exmod);
 }
+
+#ifdef SOLARIS
+#include <dlfcn.h>
+
+static void *python_dlhandle = NULL;
+
+static void
+end_dynamic_python(void)
+{
+    if (python_dlhandle) {
+ dlclose(python_dlhandle);
+ python_dlhandle = NULL;
+    }
+}
+
+static int
+python_runtime_link_init(char *libname, int verbose)
+{
+    int i;
+
+    if (python_dlhandle)
+ return OK;
+    python_dlhandle = dlopen(libname, RTLD_GLOBAL|RTLD_LAZY);
+    if (!python_dlhandle)
+    {
+ if (verbose)
+    EMSG2(_(e_loadlib), libname);
+ return FAIL;
+    }
+
+    for (i = 0; python_funcname_table[i].ptr; ++i)
+    {
+ if ((*python_funcname_table[i].ptr = dlsym(python_dlhandle,
+ python_funcname_table[i].name)) == NULL)
+ {
+    dlclose(python_dlhandle);
+    python_dlhandle = NULL;
+    if (verbose)
+ EMSG2(_(e_loadfunc), python_funcname_table[i].name);
+    return FAIL;
+ }
+    }
+
+    return OK;
+}
+
+int
+python_enabled(int verbose)
+{
+    return python_runtime_link_init("libpython2.4.so.1.0", verbose) == OK;
+}
+#endif /* SOLARIS */
 #endif /* DYNAMIC_PYTHON */
 
 /******************************************************
@@ -483,7 +547,13 @@
     ++recurse;
 
 #ifdef DYNAMIC_PYTHON
-    if (hinstPython && Py_IsInitialized())
+    if (
+#ifdef MSWIN
+ hinstPython
+#elif defined(SOLARIS)
+ python_dlhandle
+#endif
+ && Py_IsInitialized())
     {
  Python_RestoreThread();    /* enter python */
  Py_Finalize();
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Doug Kearns

On 2/15/09, Danek Duvall <[hidden email]> wrote:

<snip>

>  If
>  there are any Python script torture tests I should run, let me know; I'm
>  not sure what the best python scripts are to play with.

You could play with the distributed Python omni completion:
autoload/pythoncomplete.vim

<snip>

Regards,
Doug

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Bram Moolenaar
In reply to this post by Danek Duvall-2


Danek Duvall wrote:

> I've been wanting to code this up for a while, and almost had it a while
> back, but couldn't quite get it working, and put it aside until today.
>
> It's not ready for integration, since it's not at all tied into the
> autoconf setup, and requires that you modify src/auto/config.mk to add
> -DDYNAMIC_PYTHON to PYTHON_CFLAGS and wrap -lpython2.4 in PYTHON_LIBS with
> -zlazyload / -znolazyload, but otherwise it seems to work: python isn't
> loaded until the first python command is executed, and (as far as I've been
> able to tell) executes python code just fine after that, has("python") is
> true, etc.
>
> Comments on the patch itself are appreciated.  Suggestions on how it might
> be made to work on Linux are also appreciated, though I don't really have
> any means of testing it at the moment.  And help with getting it tied in
> with autoconf would be great; I'm not sure how to move forward on that.  If
> there are any Python script torture tests I should run, let me know; I'm
> not sure what the best python scripts are to play with.
>
> I haven't looked at doing the other interpreters yet, though I'd like to do
> that, as well as see if it's possible to dynamically load the GUI.

I haven't looked at the patch yet, but I would like to encourage others
to help make this work for as many systems as possible.  It's so much
nicer when Vim can be build with Python and the binary distributed to
systems where Python is not available.  Less versions, more flexibility.

I assume that for building the Python headers and tools are still
required, thus it only helps for when distributing a Vim binary.

--
From "know your smileys":
 :-)-O Smiling doctor with stethoscope

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Danek Duvall-2

On Sun, Feb 15, 2009 at 02:57:35PM +0100, Bram Moolenaar wrote:

> I haven't looked at the patch yet, but I would like to encourage others
> to help make this work for as many systems as possible.  It's so much
> nicer when Vim can be build with Python and the binary distributed to
> systems where Python is not available.  Less versions, more flexibility.
>
> I assume that for building the Python headers and tools are still
> required, thus it only helps for when distributing a Vim binary.

Correct.

One question I have is how flexible it should be.  I did this the way I did
because I could easily hang off the work that had been done for Windows,
but if I were to make a dynamic module -- consisting of if_python.o and
py_config.o -- then I could make one for each version of Python available
on the system at build time, and then try loading them in turn until one
was successful.  So you could build on a system that had 2.4, 2.5, and 2.6,
and work on a system that had any of the three.

Of course, fully fleshing that idea out means giving some control to the
user of which version they want to use, or a preference ordering of the
versions.

And further down that road would be to experiment with whether multiple
versions of Python can be loaded into memory at the same time.  If that's
the case, then you could have different scripts running with different
versions in the same vim session.  I don't know how useful that would be in
practice, though.

Danek

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Re: PATCH: dynamically load Python on Solaris

Danek Duvall-2
In reply to this post by Doug Kearns

On Sun, Feb 15, 2009 at 09:02:15PM +1100, Doug Kearns wrote:

> On 2/15/09, Danek Duvall <[hidden email]> wrote:
>
> >  If there are any Python script torture tests I should run, let me
> >  know; I'm not sure what the best python scripts are to play with.
>
> You could play with the distributed Python omni completion:
> autoload/pythoncomplete.vim

Ah, thanks.  Seems to work.

Danek

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Danek Duvall-2
In reply to this post by Danek Duvall-2
Okay, I've hacked configure.in to make it possible to do this from
configure.  The patch is attached.  It applies only on top of my previous
patch, as it passes the python library name in as a define.  This is gross,
but it gets the job done for now.

Thanks,
Danek

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---


--- configure.in.orig Sat Feb 14 13:53:40 2009
+++ configure.in Sun Feb 15 21:24:19 2009
@@ -608,10 +608,10 @@
 
 AC_MSG_CHECKING(--enable-pythoninterp argument)
 AC_ARG_ENABLE(pythoninterp,
- [  --enable-pythoninterp   Include Python interpreter.], ,
+ [  --enable-pythoninterp[=OPTS] Include Python interpreter. [OPTS=yes/no/dynamic]], ,
  [enable_pythoninterp="no"])
 AC_MSG_RESULT($enable_pythoninterp)
-if test "$enable_pythoninterp" = "yes"; then
+if test "$enable_pythoninterp" = "yes" -o "$enable_pythoninterp" = "dynamic"; then
   dnl -- find the python executable
   AC_PATH_PROG(vi_cv_path_python, python)
   if test "X$vi_cv_path_python" != "X"; then
@@ -668,6 +668,12 @@
  done
       ])
 
+      if test "${enable_pythoninterp}" = "dynamic"; then
+ if test "`(uname) 2>/dev/null`" != SunOS; then
+  AC_MSG_RESULT([dynamically loaded Python interpreter not supported!])
+ fi
+      fi
+
       PYTHON_CONFDIR="${vi_cv_path_python_conf}"
 
       if test "X$PYTHON_CONFDIR" = "X"; then
@@ -686,6 +692,7 @@
  @echo "python_LIBS='$(LIBS)'"
  @echo "python_SYSLIBS='$(SYSLIBS)'"
  @echo "python_LINKFORSHARED='$(LINKFORSHARED)'"
+ @echo "python_INSTSONAME='$(INSTSONAME)'"
 eof
     dnl -- delete the lines from make about Entering/Leaving directory
     eval "`cd ${PYTHON_CONFDIR} && make -f "${tmp_mkf}" __ | sed '/ directory /d'`"
@@ -697,7 +704,17 @@
       if test "${vi_cv_var_python_version}" = "1.4"; then
   vi_cv_path_python_plibs="${PYTHON_CONFDIR}/libModules.a ${PYTHON_CONFDIR}/libPython.a ${PYTHON_CONFDIR}/libObjects.a ${PYTHON_CONFDIR}/libParser.a"
       else
+ if test "${enable_pythoninterp}" = "dynamic"; then
+  vi_cv_lazyon="-zlazyload"
+  vi_cv_lazyoff="-znolazyload"
+  if test "$GCC" = "yes"; then
+    vi_cv_lazyon="-Wl,${vi_cv_lazyon}"
+    vi_cv_lazyoff="-Wl,${vi_cv_lazyoff}"
+  fi
+  vi_cv_path_python_plibs="-L${PYTHON_CONFDIR} ${vi_cv_lazyon} -lpython${vi_cv_var_python_version} ${vi_cv_lazyoff}"
+ else
   vi_cv_path_python_plibs="-L${PYTHON_CONFDIR} -lpython${vi_cv_var_python_version}"
+ fi
       fi
       vi_cv_path_python_plibs="${vi_cv_path_python_plibs} ${python_MODLIBS} ${python_LIBS} ${python_SYSLIBS} ${python_LINKFORSHARED}"
       dnl remove -ltermcap, it can conflict with an earlier -lncurses
@@ -711,6 +728,9 @@
  else
   PYTHON_CFLAGS="-I${vi_cv_path_python_pfx}/include/python${vi_cv_var_python_version} -I${vi_cv_path_python_epfx}/include/python${vi_cv_var_python_version}"
  fi
+ if test "${enable_pythoninterp}" = "dynamic"; then
+  PYTHON_CFLAGS="${PYTHON_CFLAGS} -DDYNAMIC_PYTHON -DPYTHONSONAME='\"${python_INSTSONAME}\"'"
+ fi
  PYTHON_SRC="if_python.c"
  dnl For Mac OSX 10.2 config.o is included in the Python library.
  if test "x$MACOSX" = "xyes"; then
--- if_python.c.orig.2 Sun Feb 15 21:29:10 2009
+++ if_python.c Sun Feb 15 21:29:26 2009
@@ -442,7 +442,7 @@
 int
 python_enabled(int verbose)
 {
-    return python_runtime_link_init("libpython2.4.so.1.0", verbose) == OK;
+    return python_runtime_link_init(PYTHONSONAME, verbose) == OK;
 }
 #endif /* SOLARIS */
 #endif /* DYNAMIC_PYTHON */
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Danek Duvall-2
In reply to this post by Danek Duvall-2
So here's a re-work that should allow for dynamic loading on platforms
other than Solaris.  The autoconf bits are tuned for Solaris, but change
-Kpic to -fpic, -G to -shared, and SunOS to Linux, and I think it might
work, or at least come close.

The difference here is that if_python.c itself is converted into a shared
object which can be loaded by vim.  That way, if_python.so can link simply
against python and not have to worry about the mess of dlsym calls, lazy
loading, etc, that you needed in the main program in my first attempt.
Then vim either loads or fails to load if_python.so.

New patch is attached.

Thanks,
Danek

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---


--- Makefile.orig Sat Aug  9 07:50:04 2008
+++ Makefile Mon Feb 16 01:07:36 2009
@@ -966,6 +966,8 @@
 PRINTSUBLOC = $(VIMRTLOC)$(PRINTSUBDIR)
 SCRIPTLOC = $(VIMRTLOC)
 
+VIMSOLOC = $(LIBDIR)$(VIMRTDIR)
+
 ### Only set VIMRUNTIMEDIR when VIMRTLOC is set to a different location and
 ### the runtime directory is not below it.
 #VIMRUNTIMEDIR = $(VIMRTLOC)
@@ -1334,6 +1336,7 @@
 DEST_SCRIPT = $(DESTDIR)$(SCRIPTLOC)
 DEST_PRINT = $(DESTDIR)$(PRINTSUBLOC)
 DEST_MAN_TOP = $(DESTDIR)$(MANDIR)
+DEST_SO = $(DESTDIR)$(VIMSOLOC)
 
 # We assume that the ".../man/xx/man1/" directory is for latin1 manual pages.
 # Some systems use UTF-8, but these should find the ".../man/xx.UTF-8/man1/"
@@ -1555,7 +1558,7 @@
  os_mswin.pro os_beos.pro os_vms.pro os_riscos.pro $(PERL_PRO)
 
 # Default target is making the executable and tools
-all: $(VIMTARGET) $(TOOLS) languages $(GUI_BUNDLE)
+all: $(VIMTARGET) $(PYTHON_SO) $(TOOLS) languages $(GUI_BUNDLE)
 
 tools: $(TOOLS)
 
@@ -1761,7 +1764,7 @@
 
 install_gui_extra: installgtutorbin
 
-installvim: installvimbin installtutorbin \
+installvim: installvimbin installvimso installtutorbin \
  installruntime installlinks installmanlinks
 
 #
@@ -1784,6 +1787,11 @@
 # may create a link to the new executable from /usr/bin/vi
  -$(LINKIT)
 
+installvimso: $(PYTHON_SO) $(DESTDIR)$(libdir) $(DEST_SO)
+ -$(INSTALL_PROG) $(PYTHON_SO) $(DEST_SO)
+ -$(STRIP) $(DEST_SO)/$(PYTHON_SO)
+ -chmod $(BINMOD) $(DEST_SO)/$(PYTHON_SO)
+
 # Long list of arguments for the shell script that installs the manual pages
 # for one language.
 INSTALLMANARGS = $(VIMLOC) $(SCRIPTLOC) $(VIMRCLOC) $(HELPSOURCE) $(MANMOD) \
@@ -2020,7 +2028,7 @@
  @echo You need to unpack the runtime archive before running "make install".
  test -f error
 
-$(DESTDIR)$(exec_prefix) $(DEST_BIN) \
+$(DESTDIR)$(exec_prefix) $(DEST_BIN) $(DEST_SO) \
  $(DEST_VIM) $(DEST_RT) $(DEST_HELP) \
  $(DEST_PRINT) $(DEST_COL) $(DEST_SYN) $(DEST_IND) $(DEST_FTP) \
  $(DEST_LANG) $(DEST_KMAP) $(DEST_COMP) \
@@ -2184,6 +2192,7 @@
 # We support common typing mistakes for Juergen! :-)
 clean celan: testclean
  -rm -f *.o objects/* core $(VIMTARGET).core $(VIMTARGET) vim xxd/*.o
+ -rm -f $(PYTHON_SO)
  -rm -f $(TOOLS) auto/osdef.h auto/pathdef.c auto/if_perl.c
  -rm -f conftest* *~ auto/link.sed
  -rm -rf $(APPDIR)
@@ -2429,9 +2438,15 @@
 objects/if_perlsfio.o: if_perlsfio.c
  $(CCC) -o $@ if_perlsfio.c
 
+objects/if_python_stub.o: if_python_stub.c
+ $(CCC) -o $@ if_python_stub.c
+
 objects/if_python.o: if_python.c
- $(CCC) -o $@ if_python.c
+ $(CCC) $(PYTHON_SO_CFLAGS) -o $@ if_python.c
 
+$(PYTHON_SO): $(PYTHON_SO_OBJ)
+ $(CClink) $(PYTHON_SO_LIBS) -o $@ $(PYTHON_SO_OBJ)
+
 objects/if_ruby.o: if_ruby.c
  $(CCC) -o $@ if_ruby.c
 
@@ -2503,7 +2518,7 @@
 
 objects/py_config.o: $(PYTHON_CONFDIR)/config.c
  $(CCC) -o $@ $(PYTHON_CONFDIR)/config.c \
- -I$(PYTHON_CONFDIR) -DHAVE_CONFIG_H -DNO_MAIN
+ $(PYTHON_INC) -I$(PYTHON_CONFDIR) -DHAVE_CONFIG_H -DNO_MAIN
 
 objects/py_getpath.o: $(PYTHON_CONFDIR)/getpath.c
  $(CCC) -o $@ $(PYTHON_CONFDIR)/getpath.c \
--- config.mk.in.orig Sat Jun 21 08:56:41 2008
+++ config.mk.in Mon Feb 16 00:54:57 2009
@@ -55,6 +55,11 @@
 PYTHON_OBJ = @PYTHON_OBJ@
 PYTHON_CFLAGS = @PYTHON_CFLAGS@
 PYTHON_LIBS = @PYTHON_LIBS@
+PYTHON_INC = @PYTHON_INC@
+PYTHON_SO = @PYTHON_SO@
+PYTHON_SO_OBJ = @PYTHON_SO_OBJ@
+PYTHON_SO_CFLAGS = @PYTHON_SO_CFLAGS@
+PYTHON_SO_LIBS = @PYTHON_SO_LIBS@
 PYTHON_CONFDIR = @PYTHON_CONFDIR@
 PYTHON_GETPATH_CFLAGS = @PYTHON_GETPATH_CFLAGS@
 
@@ -112,6 +117,9 @@
 ### For autoconf 2.60 and later (avoid a warning)
 datarootdir = @datarootdir@
 
+### Prefix for location of native-code plugins
+LIBDIR = @libdir@
+
 ### Prefix for location of data files
 DATADIR = @datadir@
 
--- configure.in.orig Sat Feb 14 13:53:40 2009
+++ configure.in Mon Feb 16 00:58:47 2009
@@ -608,10 +608,10 @@
 
 AC_MSG_CHECKING(--enable-pythoninterp argument)
 AC_ARG_ENABLE(pythoninterp,
- [  --enable-pythoninterp   Include Python interpreter.], ,
+ [  --enable-pythoninterp[=OPTS] Include Python interpreter. [OPTS=yes/no/dynamic]], ,
  [enable_pythoninterp="no"])
 AC_MSG_RESULT($enable_pythoninterp)
-if test "$enable_pythoninterp" = "yes"; then
+if test "$enable_pythoninterp" = "yes" -o "$enable_pythoninterp" = "dynamic"; then
   dnl -- find the python executable
   AC_PATH_PROG(vi_cv_path_python, python)
   if test "X$vi_cv_path_python" != "X"; then
@@ -668,6 +668,12 @@
  done
       ])
 
+      if test "${enable_pythoninterp}" = "dynamic"; then
+ if test "`(uname) 2>/dev/null`" != SunOS; then
+  AC_MSG_RESULT([dynamically loaded Python interpreter not supported!])
+ fi
+      fi
+
       PYTHON_CONFDIR="${vi_cv_path_python_conf}"
 
       if test "X$PYTHON_CONFDIR" = "X"; then
@@ -697,7 +703,12 @@
       if test "${vi_cv_var_python_version}" = "1.4"; then
   vi_cv_path_python_plibs="${PYTHON_CONFDIR}/libModules.a ${PYTHON_CONFDIR}/libPython.a ${PYTHON_CONFDIR}/libObjects.a ${PYTHON_CONFDIR}/libParser.a"
       else
+ if test "${enable_pythoninterp}" = "dynamic"; then
+  vi_cv_path_python_plibs=""
+  vi_cv_path_python_psolibs="-G -L${PYTHON_CONFDIR} -zignore -lpython${vi_cv_var_python_version}"
+ else
   vi_cv_path_python_plibs="-L${PYTHON_CONFDIR} -lpython${vi_cv_var_python_version}"
+ fi
       fi
       vi_cv_path_python_plibs="${vi_cv_path_python_plibs} ${python_MODLIBS} ${python_LIBS} ${python_SYSLIBS} ${python_LINKFORSHARED}"
       dnl remove -ltermcap, it can conflict with an earlier -lncurses
@@ -707,16 +718,30 @@
 
  PYTHON_LIBS="${vi_cv_path_python_plibs}"
  if test "${vi_cv_path_python_pfx}" = "${vi_cv_path_python_epfx}"; then
-  PYTHON_CFLAGS="-I${vi_cv_path_python_pfx}/include/python${vi_cv_var_python_version}"
+  PYTHON_INC="-I${vi_cv_path_python_pfx}/include/python${vi_cv_var_python_version}"
  else
-  PYTHON_CFLAGS="-I${vi_cv_path_python_pfx}/include/python${vi_cv_var_python_version} -I${vi_cv_path_python_epfx}/include/python${vi_cv_var_python_version}"
+  PYTHON_INC="-I${vi_cv_path_python_pfx}/include/python${vi_cv_var_python_version} -I${vi_cv_path_python_epfx}/include/python${vi_cv_var_python_version}"
  fi
+ if test "${enable_pythoninterp}" = "dynamic"; then
+  PYTHON_LIBS="${PYTHON_LIBS} -R\$(VIMSOLOC)"
+  PYTHON_CFLAGS="-DDYNAMIC_PYTHON"
+  PYTHON_SO_CFLAGS="${PYTHON_INC} -Kpic"
+  PYTHON_SO_LIBS="${vi_cv_path_python_psolibs}"
+  PYTHON_SO="if_python.so"
+ else
+  PYTHON_CFLAGS="${PYTHON_INC}"
+ fi
  PYTHON_SRC="if_python.c"
  dnl For Mac OSX 10.2 config.o is included in the Python library.
  if test "x$MACOSX" = "xyes"; then
   PYTHON_OBJ="objects/if_python.o"
  else
-  PYTHON_OBJ="objects/if_python.o objects/py_config.o"
+  if test "${enable_pythoninterp}" = "dynamic"; then
+    PYTHON_OBJ="objects/if_python_stub.o"
+    PYTHON_SO_OBJ="objects/if_python.o objects/py_config.o"
+  else
+    PYTHON_OBJ="objects/if_python_stub.o objects/if_python.o objects/py_config.o"
+  fi
  fi
  if test "${vi_cv_var_python_version}" = "1.4"; then
    PYTHON_OBJ="$PYTHON_OBJ objects/py_getpath.o"
@@ -775,6 +800,11 @@
   PYTHON_OBJ=
   PYTHON_LIBS=
   PYTHON_CFLAGS=
+  PYTHON_INC=
+  PYTHON_SO=
+  PYTHON_SO_OBJ=
+  PYTHON_SO_CFLAGS=
+  PYTHON_SO_LIBS=
  fi
 
       fi
@@ -789,6 +819,11 @@
 AC_SUBST(PYTHON_CFLAGS)
 AC_SUBST(PYTHON_SRC)
 AC_SUBST(PYTHON_OBJ)
+AC_SUBST(PYTHON_INC)
+AC_SUBST(PYTHON_SO)
+AC_SUBST(PYTHON_SO_OBJ)
+AC_SUBST(PYTHON_SO_CFLAGS)
+AC_SUBST(PYTHON_SO_LIBS)
 
 AC_MSG_CHECKING(--enable-tclinterp argument)
 AC_ARG_ENABLE(tclinterp,
--- if_python.c.orig Sat Feb 14 13:53:41 2009
+++ if_python.c Mon Feb 16 00:42:21 2009
@@ -85,7 +85,7 @@
 # define PY_CAN_RECURSE
 #endif
 
-#if defined(DYNAMIC_PYTHON) || defined(PROTO)
+#if (defined(DYNAMIC_PYTHON) && defined(MSWIN)) || defined(PROTO)
 # ifndef DYNAMIC_PYTHON
 #  define HINSTANCE long_u /* for generating prototypes */
 # endif
@@ -387,7 +387,7 @@
  * Internal function prototypes.
  */
 
-static void DoPythonCommand(exarg_T *, const char *);
+void DoPythonCommand(exarg_T *, const char *);
 static PyInt RangeStart;
 static PyInt RangeEnd;
 
@@ -482,7 +482,7 @@
 
     ++recurse;
 
-#ifdef DYNAMIC_PYTHON
+#if defined(DYNAMIC_PYTHON) && defined(MSWIN)
     if (hinstPython && Py_IsInitialized())
     {
  Python_RestoreThread();    /* enter python */
@@ -521,7 +521,7 @@
  /* initialise threads */
  PyEval_InitThreads();
 
-#ifdef DYNAMIC_PYTHON
+#if defined(DYNAMIC_PYTHON) && defined(MSWIN)
  get_exceptions();
 #endif
 
@@ -558,7 +558,7 @@
 /*
  * External interface
  */
-    static void
+    void
 DoPythonCommand(exarg_T *eap, const char *cmd)
 {
 #ifndef PY_CAN_RECURSE
@@ -633,69 +633,6 @@
     return;    /* keeps lint happy */
 }
 
-/*
- * ":python"
- */
-    void
-ex_python(exarg_T *eap)
-{
-    char_u *script;
-
-    script = script_get(eap, eap->arg);
-    if (!eap->skip)
-    {
- if (script == NULL)
-    DoPythonCommand(eap, (char *)eap->arg);
- else
-    DoPythonCommand(eap, (char *)script);
-    }
-    vim_free(script);
-}
-
-#define BUFFER_SIZE 1024
-
-/*
- * ":pyfile"
- */
-    void
-ex_pyfile(exarg_T *eap)
-{
-    static char buffer[BUFFER_SIZE];
-    const char *file = (char *)eap->arg;
-    char *p;
-
-    /* Have to do it like this. PyRun_SimpleFile requires you to pass a
-     * stdio file pointer, but Vim and the Python DLL are compiled with
-     * different options under Windows, meaning that stdio pointers aren't
-     * compatible between the two. Yuk.
-     *
-     * Put the string "execfile('file')" into buffer. But, we need to
-     * escape any backslashes or single quotes in the file name, so that
-     * Python won't mangle the file name.
-     */
-    strcpy(buffer, "execfile('");
-    p = buffer + 10; /* size of "execfile('" */
-
-    while (*file && p < buffer + (BUFFER_SIZE - 3))
-    {
- if (*file == '\\' || *file == '\'')
-    *p++ = '\\';
- *p++ = *file++;
-    }
-
-    /* If we didn't finish the file name, we hit a buffer overflow */
-    if (*file != '\0')
- return;
-
-    /* Put in the terminating "')" and a null */
-    *p++ = '\'';
-    *p++ = ')';
-    *p++ = '\0';
-
-    /* Execute the file */
-    DoPythonCommand(eap, buffer);
-}
-
 /******************************************************
  * 2. Python output stream: writes output via [e]msg().
  */
--- if_python_stub.c.orig Mon Feb 16 00:34:57 2009
+++ if_python_stub.c Mon Feb 16 00:42:23 2009
@@ -1,0 +1,126 @@
+/* vi:set ts=8 sts=4 sw=4: */
+#include "vim.h"
+
+#ifdef DYNAMIC_PYTHON
+#include <dlfcn.h>
+
+static void *if_python_handle;
+
+static void DoPythonCommand(exarg_T *eap, const char *cmd) {
+    (*(void (*)(exarg_T *, const char *))dlsym(if_python_handle, "DoPythonCommand"))(eap, cmd);
+}
+void python_window_free(win_T *win) {
+    (*(void (*)(win_T *))dlsym(if_python_handle, "python_window_free"))(win);
+}
+void python_buffer_free(buf_T *buf) {
+    (*(void (*)(buf_T *))dlsym(if_python_handle, "python_buffer_free"))(buf);
+}
+void python_end(void) {
+    if (if_python_handle) {
+ (*(void (*)(void))dlsym(if_python_handle, "python_end"))();
+ dlclose(if_python_handle);
+ if_python_handle = NULL;
+    }
+}
+#else
+void DoPythonCommand(exarg_T *, const char *);
+#endif
+
+    static int
+load_python(int verbose)
+{
+#ifdef DYNAMIC_PYTHON
+    if (if_python_handle)
+ return OK;
+
+    if_python_handle = dlopen("if_python.so", RTLD_NOW);
+    if (!if_python_handle)
+    {
+ EMSG2(_(e_loadlib), "if_python.so");
+ return FAIL;
+    }
+#endif
+
+    return OK;
+}
+
+    int
+python_enabled(int verbose)
+{
+    return load_python(verbose) == OK;
+}
+
+/*
+ * ":python"
+ */
+    void
+ex_python(exarg_T *eap)
+{
+    char_u *script;
+
+    if (!load_python(TRUE))
+    {
+ EMSG(_("E263: Sorry, this command is disabled, the Python library could not be loaded."));
+ return;
+    }
+
+    script = script_get(eap, eap->arg);
+    if (!eap->skip)
+    {
+ if (script == NULL)
+    DoPythonCommand(eap, (char *)eap->arg);
+ else
+    DoPythonCommand(eap, (char *)script);
+    }
+    vim_free(script);
+}
+
+#define BUFFER_SIZE 1024
+
+/*
+ * ":pyfile"
+ */
+    void
+ex_pyfile(exarg_T *eap)
+{
+    static char buffer[BUFFER_SIZE];
+    const char *file = (char *)eap->arg;
+    char *p;
+
+    if (!python_enabled(TRUE))
+    {
+ EMSG(_("E263: Sorry, this command is disabled, the Python library could not be loaded."));
+ return;
+    }
+
+    /* Have to do it like this. PyRun_SimpleFile requires you to pass a
+     * stdio file pointer, but Vim and the Python DLL are compiled with
+     * different options under Windows, meaning that stdio pointers aren't
+     * compatible between the two. Yuk.
+     *
+     * Put the string "execfile('file')" into buffer. But, we need to
+     * escape any backslashes or single quotes in the file name, so that
+     * Python won't mangle the file name.
+     */
+    strcpy(buffer, "execfile('");
+    p = buffer + 10; /* size of "execfile('" */
+
+    while (*file && p < buffer + (BUFFER_SIZE - 3))
+    {
+ if (*file == '\\' || *file == '\'')
+    *p++ = '\\';
+ *p++ = *file++;
+    }
+
+    /* If we didn't finish the file name, we hit a buffer overflow */
+    if (*file != '\0')
+ return;
+
+    /* Put in the terminating "')" and a null */
+    *p++ = '\'';
+    *p++ = ')';
+    *p++ = '\0';
+
+    /* Execute the file */
+    DoPythonCommand(eap, buffer);
+}
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Björn Winckler
In reply to this post by Danek Duvall-2

Hi Danek,

2009/2/15 Danek Duvall:
>
> And further down that road would be to experiment with whether multiple
> versions of Python can be loaded into memory at the same time.  If that's
> the case, then you could have different scripts running with different
> versions in the same vim session.  I don't know how useful that would be in
> practice, though.

Hi Danek,

This would be very useful for the Mac OS X port of Vim (MacVim) since
10.4 comes with Python 2.3 and 10.5 ships with Python 2.5.  At the
moment I link MacVim against 2.3 so that it works on both 10.4 and
10.5 but several users have requested 2.5.  I actually implemented
dynamic loading of Python for OS X but since there are Python API
changes between 2.3 and 2.5 you get a warning when trying to run on
2.3 if the binary was built using 2.5 (even though the library itself
is successfullly loaded dynamically).

Anyway, if you get around to implementing this I would be very eager
to test it and include it in MacVim.  By the way, how exactly do you
propose to do this?  Looking at your latest patch I assume you'd build
one if_python module for each version and then decide which one to
load when python is first used?

Björn

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Danek Duvall-2

björn wrote:

> 2009/2/15 Danek Duvall:
> >
> > And further down that road would be to experiment with whether multiple
> > versions of Python can be loaded into memory at the same time.  If that's
> > the case, then you could have different scripts running with different
> > versions in the same vim session.  I don't know how useful that would be in
> > practice, though.
>
> This would be very useful for the Mac OS X port of Vim (MacVim) since
> 10.4 comes with Python 2.3 and 10.5 ships with Python 2.5.  At the
> moment I link MacVim against 2.3 so that it works on both 10.4 and
> 10.5 but several users have requested 2.5.

So that speaks for having multiple versions available, but not necessarily
for having them all co-resident.

> I actually implemented dynamic loading of Python for OS X but since there
> are Python API changes between 2.3 and 2.5 you get a warning when trying
> to run on 2.3 if the binary was built using 2.5 (even though the library
> itself is successfullly loaded dynamically).

Yup, I saw that as well when playing around.

> By the way, how exactly do you propose to do this?  Looking at your
> latest patch I assume you'd build one if_python module for each version
> and then decide which one to load when python is first used?

That's the idea.  I'm just not sure how that decision should be made.  I
guess I'm looking for some guidance from Bram, though not being terribly
familiar with the vim development model, I don't know if I should be
looking elsewhere for that guidance.

At any rate, if I were to hack something together right now, I'd probably
introduce a new variable that would let you set the order:

    set pythonversions=2.3,2.4,2.5

with tags of "oldest" and "newest" available as well.  The first module
matching an element in the series that loaded properly would be the one
used, defaulting to either oldest or newest if the variable isn't set (or
if none of them match?).  The modules would need to be named consistently
-- if_python<ver>.so -- and in a collatable order, though I suppose I could
always try to query the module for the definitive version if the collation
proves too difficult.

But there might be some pitfalls behind that.  Suggestions and guidance are
welcomed.

Thanks,
Danek

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Björn Winckler

2009/2/17 Danek Duvall:

>
> björn wrote:
>
>> 2009/2/15 Danek Duvall:
>> >
>> > And further down that road would be to experiment with whether multiple
>> > versions of Python can be loaded into memory at the same time.  If that's
>> > the case, then you could have different scripts running with different
>> > versions in the same vim session.  I don't know how useful that would be in
>> > practice, though.
>>
>> This would be very useful for the Mac OS X port of Vim (MacVim) since
>> 10.4 comes with Python 2.3 and 10.5 ships with Python 2.5.  At the
>> moment I link MacVim against 2.3 so that it works on both 10.4 and
>> 10.5 but several users have requested 2.5.
>
> So that speaks for having multiple versions available, but not necessarily
> for having them all co-resident.

Yes that is all I am after -- I can't see any particular use for
having two or more co-resident.  (?)

>> By the way, how exactly do you propose to do this?  Looking at your
>> latest patch I assume you'd build one if_python module for each version
>> and then decide which one to load when python is first used?
>
> That's the idea.  I'm just not sure how that decision should be made.  I
> guess I'm looking for some guidance from Bram, though not being terribly
> familiar with the vim development model, I don't know if I should be
> looking elsewhere for that guidance.
>
> At any rate, if I were to hack something together right now, I'd probably
> introduce a new variable that would let you set the order:
>
>    set pythonversions=2.3,2.4,2.5
>
> with tags of "oldest" and "newest" available as well.  The first module
> matching an element in the series that loaded properly would be the one
> used, defaulting to either oldest or newest if the variable isn't set (or
> if none of them match?).  The modules would need to be named consistently
> -- if_python<ver>.so -- and in a collatable order, though I suppose I could
> always try to query the module for the definitive version if the collation
> proves too difficult.
>
> But there might be some pitfalls behind that.  Suggestions and guidance are
> welcomed.

I think this is overkill.  Why not just see which modules are
installed and try loading from newest to oldest?  Well, maybe it isn't
that simple since loading will probably work as long as the module is
present even if the matching python version is not installed.  But it
provides pretty much the same functionality as the option you
suggested (the user simply has to make sure that only the right module
is installed) and it means less code.  I'm pretty new to Vim
development myself, but it seems the less new options you introduce
the greater the chance that your patch will be accepted.

Anyway, as far as OS X is concerned the best way would be if the most
recent version of python installed was automatically used (judging
from the requests I've had from users) without the need of user
involvement.  Would this be possible?  (Assuming the user has the
matching if_python modules installed...in the case of OS X these would
be distributed with the Vim binary inside the so-called application
bundle.)

Björn

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Danek Duvall-2

On Tue, Feb 17, 2009 at 07:32:35PM +0100, björn wrote:

> Yes that is all I am after -- I can't see any particular use for
> having two or more co-resident.  (?)

The use case would be if you had a script that could only run with 2.3 and
another that could only run with 2.6, and you wanted to use both in the
same vim process.  I agree that it's all that worth worrying about, though.

> I think this is overkill.  Why not just see which modules are
> installed and try loading from newest to oldest?

Works for me.  I can always change it later to be fancier if people find
the simple method to not be enough.

> Well, maybe it isn't that simple since loading will probably work as long
> as the module is present even if the matching python version is not
> installed.

That'll probably depend on the features of the dynamic linker.  On Solaris,
at least, the module will fail to load if a dependency it has isn't there.

I may not get to it before this weekend, but I'll post another patch as
soon as I have it.  In the meantime, if you have a chance to try my latest
patch out on OS X, I'd be curious to know if it works there.

Thanks,
Danek

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Björn Winckler

2009/2/17 Danek Duvall:
>
> I may not get to it before this weekend, but I'll post another patch as
> soon as I have it.  In the meantime, if you have a chance to try my latest
> patch out on OS X, I'd be curious to know if it works there.

The following bit of configure.in looked a bit strange, so I changed
it.  No idea what that special "if" for MACOSX does though.

diff --git a/src/configure.in b/src/configure.in
index b623c6f..bd32b12 100644
--- a/src/configure.in
+++ b/src/configure.in
@@ -742,16 +742,12 @@ eof
        fi
        PYTHON_SRC="if_python.c"
        dnl For Mac OSX 10.2 config.o is included in the Python library.
-       if test "x$MACOSX" = "xyes"; then
-         PYTHON_OBJ="objects/if_python.o"
-       else
-         if test "${enable_pythoninterp}" = "dynamic"; then
-           PYTHON_OBJ="objects/if_python_stub.o"
-           PYTHON_SO_OBJ="objects/if_python.o objects/py_config.o"
-         else
-           PYTHON_OBJ="objects/if_python_stub.o objects/if_python.o objects/py_
-         fi
-       fi
+        if test "${enable_pythoninterp}" = "dynamic"; then
+          PYTHON_OBJ="objects/if_python_stub.o"
+          PYTHON_SO_OBJ="objects/if_python.o objects/py_config.o"
+        else
+          PYTHON_OBJ="objects/if_python_stub.o objects/if_python.o objects/py_c
+        fi
        if test "${vi_cv_var_python_version}" = "1.4"; then
           PYTHON_OBJ="$PYTHON_OBJ objects/py_getpath.o"
        fi

With this change I did regenerated the configure script and tried
building but something's up but I haven't got time to investigate
right now.  Probably just some flag to the compiler/linker that is
missing...but I get the following errors:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall
-Wno-unknown-pragmas -pipe -I. -Iproto -DMACOS_X_UNIX -no-cpp-precomp
-I/Developer/Headers/FlatCarbon  -g -O -D_FORTIFY_SOURCE=1
-DDYNAMIC_PYTHON
-I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-Kpic -o objects/if_python.o if_python.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall
-Wno-unknown-pragmas -pipe -I. -Iproto -DMACOS_X_UNIX -no-cpp-precomp
-I/Developer/Headers/FlatCarbon  -g -O -D_FORTIFY_SOURCE=1
-DDYNAMIC_PYTHON    -o objects/py_config.o
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/config.c
\
                -I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-I/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config
-DHAVE_CONFIG_H -DNO_MAIN
gcc  -o if_python.so objects/if_python.o objects/py_config.o
Undefined symbols:
  "_initimp", referenced from:
      __PyImport_Inittab in py_config.o
  "_ml_get_buf", referenced from:
      _RBSlice in if_python.o
      _GetBufferLine in if_python.o
  "_u_savesub", referenced from:
      _SetBufferLine in if_python.o
  "_PyInt_Type", referenced from:
      _PyInt_Type$non_lazy_ptr in if_python.o
  "_ml_append", referenced from:
      _RBAssSlice in if_python.o
      _RBAppend in if_python.o
      _RBAppend in if_python.o
  "_win_setwidth", referenced from:
      _WindowSetattr in if_python.o
  "_init_symtable", referenced from:
      __PyImport_Inittab in py_config.o
  "_curwin", referenced from:
      _curwin$non_lazy_ptr in if_python.o

-snip-

I'll look into it later on, but the compilation at least worked
fine...I just have to get the dynamic library to work (any ideas?).

Björn

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Re: PATCH: dynamically load Python on Solaris

Danek Duvall-2

On Tue, Feb 17, 2009 at 10:42:00PM +0100, björn wrote:

> The following bit of configure.in looked a bit strange, so I changed
> it.  No idea what that special "if" for MACOSX does though.

Well, there's that comment:

    dnl For Mac OSX 10.2 config.o is included in the Python library.

Can't speak to its relevance, though.

> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall
> -Wno-unknown-pragmas -pipe -I. -Iproto -DMACOS_X_UNIX -no-cpp-precomp
> -I/Developer/Headers/FlatCarbon  -g -O -D_FORTIFY_SOURCE=1
> -DDYNAMIC_PYTHON
> -I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
> -Kpic -o objects/if_python.o if_python.c

-Kpic is specific to the Sun compiler.  I'm not sure what gcc did with
that, but it should probably be -fpic.

> gcc  -o if_python.so objects/if_python.o objects/py_config.o
> Undefined symbols:
>   "_initimp", referenced from:
>       __PyImport_Inittab in py_config.o
>   "_ml_get_buf", referenced from:
>       _RBSlice in if_python.o
>       _GetBufferLine in if_python.o
>   "_u_savesub", referenced from:
>       _SetBufferLine in if_python.o
>   "_PyInt_Type", referenced from:
>       _PyInt_Type$non_lazy_ptr in if_python.o
>   "_ml_append", referenced from:
>       _RBAssSlice in if_python.o
>       _RBAppend in if_python.o
>       _RBAppend in if_python.o
>   "_win_setwidth", referenced from:
>       _WindowSetattr in if_python.o
>   "_init_symtable", referenced from:
>       __PyImport_Inittab in py_config.o
>   "_curwin", referenced from:
>       _curwin$non_lazy_ptr in if_python.o

This is probably happenine because gcc isn't being told to create a shared
library.  My patch used -G to pass to Studio cc, but gcc takes -shared.

Not sure if those two changes will be sufficient, but they're likely
necessary.

Danek

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Re: PATCH: dynamically load Python on Solaris

Björn Winckler

2009/2/17 Danek Duvall:

>
> On Tue, Feb 17, 2009 at 10:42:00PM +0100, björn wrote:
>
>> The following bit of configure.in looked a bit strange, so I changed
>> it.  No idea what that special "if" for MACOSX does though.
>
> Well, there's that comment:
>
>    dnl For Mac OSX 10.2 config.o is included in the Python library.
>
> Can't speak to its relevance, though.
>
>> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall
>> -Wno-unknown-pragmas -pipe -I. -Iproto -DMACOS_X_UNIX -no-cpp-precomp
>> -I/Developer/Headers/FlatCarbon  -g -O -D_FORTIFY_SOURCE=1
>> -DDYNAMIC_PYTHON
>> -I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
>> -Kpic -o objects/if_python.o if_python.c
>
> -Kpic is specific to the Sun compiler.  I'm not sure what gcc did with
> that, but it should probably be -fpic.
>
>> gcc  -o if_python.so objects/if_python.o objects/py_config.o
>> Undefined symbols:
>>   "_initimp", referenced from:
>>       __PyImport_Inittab in py_config.o
>>   "_ml_get_buf", referenced from:
>>       _RBSlice in if_python.o
>>       _GetBufferLine in if_python.o
>>   "_u_savesub", referenced from:
>>       _SetBufferLine in if_python.o
>>   "_PyInt_Type", referenced from:
>>       _PyInt_Type$non_lazy_ptr in if_python.o
>>   "_ml_append", referenced from:
>>       _RBAssSlice in if_python.o
>>       _RBAppend in if_python.o
>>       _RBAppend in if_python.o
>>   "_win_setwidth", referenced from:
>>       _WindowSetattr in if_python.o
>>   "_init_symtable", referenced from:
>>       __PyImport_Inittab in py_config.o
>>   "_curwin", referenced from:
>>       _curwin$non_lazy_ptr in if_python.o
>
> This is probably happenine because gcc isn't being told to create a shared
> library.  My patch used -G to pass to Studio cc, but gcc takes -shared.
>
> Not sure if those two changes will be sufficient, but they're likely
> necessary.

Well, this is turning out to be quite complicated.  After quite a bit
of searching I found that passing

-dynamic -undefined suppress -flat_namespace

when linking if_python.so gets rid of all those error messages.  So
the relevant lines inside Makefile should say something like:

$(PYTHON_SO): $(PYTHON_SO_OBJ)
        $(CClink) -dynamic -undefined suppress -flat_namespace
$(PYTHON_SO_LIBS) -o $@ $(PYTHON_SO_OBJ)

However, trying ":py print 'hi'" inside Vim results in a crash (SEGV).
 I know that's not at all helpful but I just wanted to say that I am
trying to get this patch to work on OS X.  To anybody else using OS X:
feel free to help me out here.  At any rate, I'll give this another go
when I get a chance again (next weekend perhaps).

Björn

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Danek Duvall-2

On Sun, Feb 22, 2009 at 07:04:08PM +0100, bj�rn wrote:

> Well, this is turning out to be quite complicated.  After quite a bit
> of searching I found that passing
>
> -dynamic -undefined suppress -flat_namespace
>
> when linking if_python.so gets rid of all those error messages.  So
> the relevant lines inside Makefile should say something like:

Hm.  Try perhaps -dynamiclib instead of -dynamic?  You could also see how
the Python dynamic modules are compiled, since they're likely loaded by the
Python interpreter the same way we're loading this module in vim.

Danek

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: dynamically load Python on Solaris

Björn Winckler

2009/2/22 Danek Duvall:

>
> On Sun, Feb 22, 2009 at 07:04:08PM +0100, bj�rn wrote:
>
>> Well, this is turning out to be quite complicated.  After quite a bit
>> of searching I found that passing
>>
>> -dynamic -undefined suppress -flat_namespace
>>
>> when linking if_python.so gets rid of all those error messages.  So
>> the relevant lines inside Makefile should say something like:
>
> Hm.  Try perhaps -dynamiclib instead of -dynamic?  You could also see how
> the Python dynamic modules are compiled, since they're likely loaded by the
> Python interpreter the same way we're loading this module in vim.

After lots of fiddling it turns out it may be as simple as swapping
-dynamic for -bundle (so your suggestion was good).

At any rate, I've got the simple ":py print 'hi'" test working now but
I made a few other changes along the way so I'm not sure that was the
only necessary change.  Hold on...yes, if I swap back to -dynamic I
get "Bus Error" again so -bundle is what is needed.  The other two
flags are necessary to avoid masses of linking errors.

I'm looking forward to a patch with dynamic loading of the most recent
Python version!  I know that a lot of MacVim users will appreciate
this feature.

Björn

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---