On 08/23/2011 07:09 PM, James Vega wrote:
On Tue, Aug 23, 2011 at 08:37:09PM +0400, ZyX wrote:
Reply to message «Re: :python forwarding to :py3 and vice-versa in case of
incompatibility»,
sent 15:57:44 23 August 2011, Tuesday
by Roland Puntaier:
Here I meant the scenario, where we would go without loading the python
shared object (SO).
Then we would have to do a AC_DEFINE() in the configure.in with the
version.
In that scenario has('python3') would not load the SO, but since
configured, would return true.
I suggest seeking for more information at this point: at least, check whether
python3 so or, especially, DLL exists and only then return true. Especially
because if I am not mistaking, vim without cream is compiled with py3 support,
but this does not guarantee that :py3 will actually work (in my Gentoo adding
python USE flag to vim will also install python, so this is not a problem).
Won't the following work: fork and load library in child, then make it report
about errors and exit?
Another option is to make the language-binding code standalone modules
that are linked with the relevant libraries and Vim dlopen()s the
language modules (as Danek Duvall suggested[0]) instead of having the
language bindings dlopen() the language libraries.
This would also fix the current problem that's preventing me from
enabling dynamic loading for the Debian packages (and I'd imagine
similarly for other binary distributions). Basically, the current
implementation makes it difficult to properly express the library
dependency, so when a new version of the library is introduced there's
no easy way to know whether Vim needs to be rebuilt to work with the new
library version (c.f., discussion in Debian's BTS[1]). With the
standalone modules, it's obvious what the library dependency is since
the module is directly linked to the library.
[0]: http://thread.gmane.org/gmane.editors.vim.devel/22759/focus=22765
[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611573
The title of this thread is not valid any more. The problem initiating the
thread was that has('python') issued an error message. Currently it's about
whether has('python') should load the library. I think that's not a problem.
Possibly Bram agrees.
The latest contributions made the context broader again. For this let me
summarize the problem about Python3 embedding in general.
1) In most Linux distros it is not possible to import Python extension
libraries
like termios unless a dynamic VIM Python embedding uses RTLD_GLOBAL for
dlopen.
It's in the way Python was compiled for these distros.
Debian e.g. has a statically build Python package and in addition a dynamic
libpython. One Python with binary extensions configured with
--enable-shared
and the problem wouldn't be there.
2) Now using RTLD_GLOBAL would mix the namespaces from Python2.x and
Python3.x,
therefore both are not possible. When I ported to Python3 ([1]) and the
problem arose the idea to make an extra SO, which binds to either
Python2.x or
Python3.x, thus keeping the symbols separate, was there. Then VIM would
have to
be compiled to allow the shared object embedding have access to its symbols
([0]). Then actually all interpreters best should be embedded that way
and allow
to add embeddings later on for specific interpreter versions.
3) The current embedding idea: If a distro has a symbolic link
libpyton2.so and
libpython3.so to the actual version and VIM is configured for both
Python2 and
Python3, then if such a libpythonX.so is there then VIM has the
embedding else
not. I need to add, that actually currently VIM's configure doesn't allow to
specify the python SO. One needs to change auto/config.mk after configure.
In general that's not so bad, expecially if that Python with all binary
extension modules was configured with --enable-shared.
4) Anyway, there are these distros that don't have these --enable-shared
configured Python2.x and Python3.x. So one VIM instance cannot use :py3 and
:python together. The first call will determine which python embedding is
activated. has('python') or has('python3') does also activate the version.
5) I would keep VIM Python embedding it this way for now.
I would like distro's to better consider to the current VIM python3
embedding.
Links:
[0]
Link to dlopen wiki:
http://en.wikipedia.org/wiki/Dynamic_loading#UNIX-like_operating_systems_.28Linux.2C_.2ABSD.2C_Mac_OS_X.2C_Solaris.2C_etc..29_3
[1]
Link to python3 embedding thread:
http://groups.google.com/group/vim_dev/browse_thread/thread/164c2a02f73046e9#
@James: Would a solution like in 3) work for debian?
--
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
