Hi Roberto,

  I've:
    * compiled python26_plugin.so and python27_plugin.so
    * installed them into /usr/lib/uwsgi/plugins (which is defined as
plugin location in buildconf for uWSGI binary)
    * made symlink /usr/lib/uwsgi/plugins/python_plugin.so pointing at
/usr/lib/uwsgi/plugins/python26_plugin.so

  When I am trying to run uWSGI with '--plugins python' option, I am
receiving error '/usr/lib/uwsgi/plugins/python_plugin.so: undefined
symbol: python_plugin'.

  Looking at uWSGI sources I've understood that it is not the bug but an
implementation detail of plugin system.

  uWSGI concatenates plugin name (given in command line) to '_plugin'
string and takes appropriately named symbol from loaded plugin's shared
library. So for '--plugins python', uWSGI looks for 'python_plugin'
symbol in python_plugin.so, but didn't found it. As python_plugin.so
symlinked to python26_plugin.so, 'python26_plugin' symbol must be looked
for.

  In thinking further, I've failed in finding of simple solution
(without patching of uWSGI sources) for giving to user possibility of
plugin loading through differently named symlink AND keeping possibility
of plugin loading by it's real name (i.e. allowing '--plugins python'
AND '--plugins python26').

  This feature is needed for using of Debian alternatives system. I
provide plugins compiled for all available Python runtimes:
python26_plugin.so, python27_plugin.so. And made additional symlink to
plugin for default Python runtime (python_plugin.so ->
python26_plugin.so) -- through alternatives system (python27_plugin.so
is also added to alternatives for python_plugin.so, but with priority
lower than python26_plugin.so).

  So should I patch uWSGI source for seeking symbol different from given
plugin name? Or there is simpler way, which I missed?
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to