On 08.09.2010 22:02:50
b...@moolenaar.net wrote:
> James Vega wrote:
> > On Mon, Aug 9, 2010 at 9:49 AM, Roland Puntaier
> > <roland.punta...@br-automation.com> wrote:
> > > On Mon, 09 Aug 2010 13:49:43
> > > Andy Kittner <and...@gmx.de> wrote:
> > >> > > I made the test in Vim 7.3: After removing RTLD_GLOBAL there
wasno
> > >> > > crash
> > >> > > any more.
> > >> >
> > >> > If I'm not mistaken this flag was added to make "import termios"
work.
> > >> > Or something like that.
> > >>
> > >> The issue was that at least on some systems pythons C-
> Extensions seemingly
> > >> aren't linked against the python shared library, therefore they
can't be
> > >> imported unless the host application provides the required symbols.
> > >>
> > >> See this thread: "Linking errors when compiled with both python and
> > >> python3"
> > >>
> > >
http://groups.google.com/group/vim_dev/browse_frm/thread/10be77eb81ad1c2d/fed7c6d9e3932ef5?tvc=1
> > >
> > > I had the same problem with PyQt 4.7, first, but at a later try it
worked,
> > > probably because that linked against libpython 3.1.2.
> > > Andy reported termios to work as well on his system.
> >
> > > Maybe we can optimistically assume that for most python
> libraries / systems
> > > it works.
> > >
> > > I would opt for the following:
> > >
> > > If only one, Python 2.x xor Python 3.x, is configured (and if
> > > DYNAMIC_PYTHON), then use RTLD_GLOBAL:
> > > #define load_dll(n) dlopen((n), RTLD_LAZY|RTLD_GLOBAL)
> > >
> > > If both are configured use without RTLD_GLOBAL:
> > > #define load_dll(n) dlopen((n),RTLD_LAZY)
> >
> > I would instead suggest a configure-time check to determine whether
it's
> > possible to load one of the lib-dynload modules without RTLD_GLOBAL
set.
> > Simply deciding not to use RTLD_GLOBAL because both Python versions
have
> > been chosen means that neither will work on systems where the
> > lib-dynload modules aren't linked against libpython since some of the
> > lib-dynload modules are always used by Python.
>
> What do you suggest we do when RTLD_GLOBAL is needed? Disallow building
> with two versions of Python? Or restrict use at runtime, as it is now?
> We could add an option to switch using RTLD_GLOBAL on/off, but it's
> really ugly. I would rather tell users to build two versions of Vim,
> one with Python 2 and one with Python 3.
So without RTLD_GLOBAL we have found that certain python C extension
modules that were not linked to libpython cannot be loaded.
This is less a problem than a crash.
It can also be tackled by recompiling that extension module or the
system package. For termios, I suppose recompiling python with
--enable-shared should work.
My assumption is that certain distros distribute python without
--enable-shared and the libpython gets into the system by other packages.
On the other hand a crash is not acceptable and thus RTLD_GLOBAL when both
python version are enable is not acceptable.
To find out during configuration is expensive and the outcome is only that
enabling both can lead to one, possibly both version with reduced
functionality.
Such a message could be issued at configuration time, but without the
expense to actually verify, whether there will be reduced functionality.
To disable one python version either at configuration time or runtime is
against the intention of the user to have both enabled.
Maybe the user can live with the reduced python functionality. If not,
there are options:
1) reconfigure vim for one python version only
2) recompile and properly link the problematic library, or python
as a whole in case of its standard libraries.
Regards,
Roland
--
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
