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
> >
> > Hi Bram,
> >
> > I missed that thread.
> >
> > 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 the problematic termios was older or not linked against libpython,
> > because it was not there at the time termios was configured.
>
> termios is a standard module in the Python distribution, so it seems to
> be up to the build process that's used. I've checked my Fedora system
> and the lib-dynload modules there aren't linked against libpython
> either. So, it looks like at least Debian and Red Hat based distros
> don't link the lib-dynload modules against libpython.
>
> > 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.
--
'Well, here's something to occupy you and keep your mind off things.'
'It won't work, I have an exceptionally large mind.'
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
/// Bram Moolenaar -- b...@moolenaar.net -- 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.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
