Newbie questions regarding installation and python shared library

[Sonoud]

Dear all,

I am a newbie and just started to learn python.

(1)
In the installation page, it says "Python should preferably be
available as a shared library.".
What does this mean? I am running openSUSE 11.0. I installed python
from repo with rpm package. how can I check if python is available as
a shared library or static library?

(2)
I successfully installed mod_wsgi from repo as well with rpm pack.
Apache successfully loaded mod_wsgi with the description: "Apache/
2.2.8 (Linux/SUSE) PHP/5.2.6 with Suhosin-Patch mod_python/3.3.1
Python/2.5.2 mod_wsgi/2.3 configured. "
In the installation issues page, it says "In the optimal case, when
mod_wsgi is compiled the resulting Apache module should be less than
250 Kbytes in size. If this is not the case and the module is over 1MB
in size, it indicates that...."
I checked the size of mod_wsgi.so, it has size 1.6M. Is this a
problem? too big? slow in performance?

Thanks a lot for your attention and answers in advance.

- Song.

[Graham Dumpleton]

2008/10/9 Sonoud <son...@gmail.com>:

The easiest way to determine if Python shared library exists and is
being used by mod_wsgi module is to run 'ldd' on the mod_wsgi.so file.
An example of this is presented in:

http://code.google.com/p/modwsgi/wiki/InstallationIssues

For example:

$ ldd mod_wsgi.so
linux-vdso.so.1 => (0x00007fffeb3fe000)
libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0 (0x00002adebf94d000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002adebfcba000)
libdl.so.2 => /lib/libdl.so.2 (0x00002adebfed6000)
libutil.so.1 => /lib/libutil.so.1 (0x00002adec00da000)
libc.so.6 => /lib/libc.so.6 (0x00002adec02dd000)
libm.so.6 => /lib/libm.so.6 (0x00002adec0635000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

If you do not see a dependency on libpythonX.Y.so, then mod_wsgi isn't
using a Python shared library.

If not using shared library, it can still work, but to avoid conflicts
and problems with mod_python you should disable mod_python and not use
it in Apache at the same time. Ensure that when disabling mod_python
to fully 'stop' Apache as mod_python doesn't shutdown properly and so
it may not unload properly and for a 'restart' may still cause
problems.

Graham

[Sonoud]

Dear Graham,

Thanks a lot for your reply.
I just checked with ldd command. here is the output:

$ ldd mod_wsgi.so
linux-gate.so.1 => (0xffffe000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7e53000)
libdl.so.2 => /lib/libdl.so.2 (0xb7e4f000)
libutil.so.1 => /lib/libutil.so.1 (0xb7e4b000)
libc.so.6 => /lib/libc.so.6 (0xb7d08000)
/lib/ld-linux.so.2 (0xb7fd1000)

You can see that no libpythonX.Y.so dependency.
I installed all rpm packages via yast2, a package management software
in openSUSE.
Actually, binary linux platform encourage people to install things via
repo. This should be same to redhat, fedora, ubuntu, etc...

Is there a way to install python as shared library from repo?
Is the compling python the only way to do it?

Thanks a lot for your valuable time.

- Song

On Oct 10, 9:36 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:

[Graham Dumpleton]

2008/10/10 Sonoud <son...@gmail.com>:

>
> Dear Graham,
>
> Thanks a lot for your reply.
> I just checked with ldd command. here is the output:
>
> $ ldd mod_wsgi.so
> linux-gate.so.1 => (0xffffe000)
> libpthread.so.0 => /lib/libpthread.so.0 (0xb7e53000)
> libdl.so.2 => /lib/libdl.so.2 (0xb7e4f000)
> libutil.so.1 => /lib/libutil.so.1 (0xb7e4b000)
> libc.so.6 => /lib/libc.so.6 (0xb7d08000)
> /lib/ld-linux.so.2 (0xb7fd1000)
>
> You can see that no libpythonX.Y.so dependency.
> I installed all rpm packages via yast2, a package management software
> in openSUSE.
> Actually, binary linux platform encourage people to install things via
> repo. This should be same to redhat, fedora, ubuntu, etc...
>
> Is there a way to install python as shared library from repo?
> Is the compling python the only way to do it?
>
> Thanks a lot for your valuable time.

It may already provide a shared library, but default Python
installation isn't friendly to people linking against it and put the
static and shared versions of Python libraries in different locations
when by rights they should be available in the same location. Most
distributions fix this problem, but looks like SUSE doesn't.

It might be argued that mod_wsgi could look in both locations, but
problem is that can only be sure about the location of the static
library as where the shared library may be may not be obvious,
especially on platforms where they try and separate 32 bit and 64 bit
Python installations.

What you should do is search for libpythonX.Y.so on your system,
substituting actual Python major/minor Python version for X.Y. On a
single architecture Linux install, this would normally be in
'/usr/lib'. That should then be symlinked to appear in the Python
'config' directory, ie., '/usr/lib/pythonX.Y/config' where the static
library exists.

Do that and when compiling mod_wsgi from source code, it should then
find the shared library along side the static library and used shared
library in preference to static library.

Graham

[Giorgos Fournarakis]

Hello! 

I did pip install mod_wsgi in a python 3.8.3 (installed with CONFIGURE_OPTS=--enable-shared pyenv install 3.8.3) pyenv virtualenv  

following the documentation instructions on an Ubuntu 16.04 server with apache 2.4.41 and got a wsgi.so file over 1MB in size.

ldd gives the required shared libraries exactly as the documentation describes it in Lack Of Python Shared Library

~/.pyenv/versions/3.8.3/envs/venv_3.8.3/lib/python3.8/site-packages/mod_wsgi/server$ ldd mod_wsgi-py38.cpython-38-x86_64-linux-gnu.so
linux-vdso.so.1 =>  (0x00007ffd997fd000)
libpython3.8.so.1.0 => /home/directory/.pyenv/versions/3.8.3/lib/libpython3.8.so.1.0 (0x00007fe199a12000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe1997f5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe19942b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe199227000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fe199024000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe198d1b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe19a1fc000)

Is this something that I should take care of?

P.S I saw the older post [modwsgi] Size of mod_wsgi.so when built with python shared library but the difference in size is big enough so to think that might be a good reason to ask about it.

[Graham Dumpleton]

That figure of 1MB was from a very very long time ago. One would expect the size to be greater now since lot more features have been added. Size also depends on whether your Python installation is building optimised images or not.

What is the actual size of the mod_wsgi.so file, you don't actually say?

--
You received this message because you are subscribed to the Google Groups "modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/7d416377-bdd2-4245-8cbb-71551bc1ae9fo%40googlegroups.com.

[Giorgos Fournarakis]

Yes, that was my concern, the size of mod_wsgi.so. 

Thank you Graham

To unsubscribe from this group and stop receiving emails from it, send an email to mod...@googlegroups.com.

[Graham Dumpleton]

You still aren't saying what the size of the mod_wsgi.so file is.

To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/147b71fd-4e9e-44fc-82f3-3f813801457ao%40googlegroups.com.

[George Fournarakis]

Oh sorry,

mod_wsgi.so size in my situation is 1157792 bytes

To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/B5A000D6-7C51-4459-B950-0BEB96D22951%40gmail.com.

[Graham Dumpleton]

That is totally fine. The issue is when it is getting up to 10MB or so, which indicates the Python library had been statically linked into it. These days I am not even sure that it is possible for it to happen. Things have changed about how static objects are built with 64 bit systems such that trying to link a static library into a dynamic object possibly has a tendency to always fails.

To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/0bb701d652df%2440575c20%24c1061460%24%40gmail.com.