[issue10243] Packaged Pythons

[Max Skaller]

Max Skaller <max.skaller at gmail.com> added the comment:

On Sat, Oct 30, 2010 at 6:40 PM, Martin v. Löwis <report at bugs.python.org>wrote:

It may be there is none. You need to read the bit where I explain that I am
not building Python, I'm grabbing pre-made packages, for OSX and for Ubuntu.

The problem is that these packages don't seem to supply a dynamic link
version.

My problem cannot be solved by telling me I can build Python myself with
the --enable-shared switch, because I am not the client. I am a vendor
supplying a tool that can generate Python shared libraries which cannot run
unless the CLIENT has a shared library version of libpython. So you're
telling me to tell THEM to build Python with --enable-shared switch which is
out of the question for many of them, who may, for example, be programmers
working in a shop where they do not have the ability to change the system
installed by their system admin.

So the problem is that the *packagers* are not supplying the dynamic lib.

Surely that is not the Python dev's issue directly, but it IS an issue the
Python dev's can do something about, by talking to the packagers.

Anyhow, I will give up. I can't test the feature of the compiler I have
implemented
because I don't have a libpython.so and I have no intention of building one,
because I can't expect all those Python users out there to do it either.

It seems you really don't understand the requirements for dynamic linking:
my application code is exclusively in a dlopen()d shared library, so if it
is
used AS a python module or it wants itself to USE a Python extension
module OR Python interpreter itself, it cannot do so.

The top level application is a fixed mainline which does not include
libpython.a or any such symbols.

It's a basic design principle, Meyer called it "the principle of explicit
interfaces"
which means: if you depend on something make the dependency explicit.

Extension modules which do not *explicitly* link against libpython break
this rule.

----------
Added file: http://bugs.python.org/file19480/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10243>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Sat, Oct 30, 2010 at 6:40 PM, Martin v. Löwis <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Martin v. Löwis &lt;<a href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br>
<div class="im"><br>
&gt; Python 2.6, for example, does ship a shared library.<br><br></div>
<br>
I fail to see the bug in this report.<br><br></blockquote><div><br>It may be there is none. You need to read the bit where I explain that I am not building Python, I&#39;m grabbing pre-made packages, for OSX and for Ubuntu.<br>
<br>The problem is that these packages don&#39;t seem to supply a dynamic link version.<br><br>My problem cannot be solved by telling me I can build Python myself with<br>the --enable-shared switch, because I am not the client. I am a vendor supplying a tool that can generate Python shared libraries which cannot run unless the CLIENT has a shared library version of libpython. So you&#39;re telling me to tell THEM to build Python with --enable-shared switch which is out of the question for many of them, who may, for example, be programmers working in a shop where they do not have the ability to change the system installed by their system admin.<br>
 <br>So the problem is that the *packagers* are not supplying the dynamic lib.<br><br>Surely that is not the Python dev&#39;s issue directly, but it IS an issue the Python dev&#39;s can do something about, by talking to the packagers.<br>
<br>Anyhow, I will give up. I can&#39;t test the feature of the compiler I have implemented<br>because I don&#39;t have a libpython.so and I have no intention of building one,<br>because I can&#39;t expect all those Python users out there to do it either.<br>
<br>It seems you really don&#39;t understand the requirements for dynamic linking:<br>my application code is exclusively in a dlopen()d shared library, so if it is<br>used AS a python module or it wants itself to USE a Python extension<br>
module OR Python interpreter itself, it cannot do so.<br><br>The top level application is a fixed mainline which does not include<br>libpython.a or any such symbols.<br><br>It&#39;s a basic design principle, Meyer called it &quot;the principle of explicit interfaces&quot;<br>
which means: if you depend on something make the dependency explicit.<br><br>Extension modules which do not *explicitly* link against libpython break<br>this rule.<br><br><br></div></div>