Max Skaller <max.skal...@gmail.com> added the comment:
On Sat, Oct 30, 2010 at 6:40 PM, Martin v. Löwis <rep...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue10243>
_______________________________________
<br><br><div class="gmail_quote">On Sat, Oct 30, 2010 at 6:40 PM, Martin v.
Löwis <span dir="ltr"><<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>></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 <<a
href="mailto:mar...@v.loewis.de";>mar...@v.loewis.de</a>> added the
comment:<br>
<div class="im"><br>
> 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'm grabbing pre-made packages, for OSX and for Ubuntu.<br>
<br>The problem is that these packages don'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'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's issue directly, but it IS
an issue the Python dev's can do something about, by talking to the
packagers.<br>
<br>Anyhow, I will give up. I can't test the feature of the compiler I have
implemented<br>because I don't have a libpython.so and I have no intention
of building one,<br>because I can't expect all those Python users out there
to do it either.<br>
<br>It seems you really don'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's a basic design principle, Meyer called it
"the principle of explicit interfaces"<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>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
