Home > Mobile >  centos 7, compiled python 3.10, undefined symbol GENERAL_NAME_free
centos 7, compiled python 3.10, undefined symbol GENERAL_NAME_free

Time:06-18

I'm getting an error trying to start apache which uses mod_wsgi 4.9.1 in a virtual environment.

On my centos 7 system, I compiled python 3.10, which is altinstalled to /usr/local/bin/python3.10

I have a virtualenv, but may have initially built mod_wsgi with an earlier version of python 3.10 (I was having trouble getting python to build correctly). However, my last attempt I used

pip install --ignore-installed --no-cache-dir mod_wsgi==4.9.1 --no-binary mod_wsgi

to try to get it to build with the latest python3.10 (I tried several pip installs, starting with just --no-cache-dir)

Note I am trying to upgrade several applications to python3.10, from centos7 yum installed python 3.6, mod_wsgi 4.7.0, which was working. So this likely has something to do with my python installation, or connecting mod_wsgi to the python installation.

I tried running mod_wsgi-express setup-server, and get these results

$ sudo LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/custom-openssl/lib /root/bin/init-mod_wsgi-express runningroutes sandbox.routes.loutilities.com routesmgr routesmgr 8002
Server URL         : http://proxysvr.loutilities.com:8002/
Server Root        : /etc/mod_wsgi-express/sandbox.routes.loutilities.com
Server Conf        : /etc/mod_wsgi-express/sandbox.routes.loutilities.com/httpd.conf
Error Log File     : /etc/mod_wsgi-express/sandbox.routes.loutilities.com/error_log (warn)
Rewrite Rules      : /etc/mod_wsgi-express/sandbox.routes.loutilities.com/rewrite.conf
Environ Variables  : /etc/mod_wsgi-express/sandbox.routes.loutilities.com/envvars
Control Script     : /etc/mod_wsgi-express/sandbox.routes.loutilities.com/apachectl
Operating Mode     : daemon
Request Capacity   : 5 (1 process * 5 threads)
Request Timeout    : 60 (seconds)
Startup Timeout    : 15 (seconds)
Queue Backlog      : 100 (connections)
Queue Timeout      : 45 (seconds)
Server Capacity    : 20 (event/worker), 20 (prefork)
Server Backlog     : 500 (connections)
Locale Setting     : en_US.UTF-8

where

$ sudo cat /root/bin/init-mod_wsgi-express
#!/bin/bash
if [[ $# -lt 5 ]] ; then
   echo "usage:"
   echo "    init-mod_wsgi-express project servername user group port"
   exit 0
fi

source /var/www/$2/venv/bin/activate
mod_wsgi-express setup-server --server-name proxysvr.loutilities.com --port $5 --user $3 --group $4 /var/www/$2/$1/$1/$1.wsgi --working-directory /var/www/$2/$1/$1/ --server-root /etc/mod_wsgi-express/$2
deactivate

but I see an error when trying to start the created apachectl file

$ sudo /etc/mod_wsgi-express/sandbox.routes.loutilities.com/apachectl start
httpd (mod_wsgi-express): Syntax error on line 163 of /etc/mod_wsgi-express/sandbox.routes.loutilities.com/httpd.conf: Cannot load /var/www/sandbox.routes.loutilities.com/venv/lib/python3.10/site-packages/mod_wsgi/server/mod_wsgi-py310.cpython-310-x86_64-linux-gnu.so into server: /var/www/sandbox.routes.loutilities.com/venv/lib/python3.10/site-packages/mod_wsgi/server/mod_wsgi-py310.cpython-310-x86_64-linux-gnu.so: undefined symbol: GENERAL_NAME_free

I notice the following from the python build directory

$ grep -R GENERAL_NAME_free . 
./Modules/_ssl.c: sk_GENERAL_NAME_pop_free(names, GENERAL_NAME_free); 
Binary file ./Modules/_ssl.o matches 
Binary file ./python matches 
Binary file ./libpython3.10.a matches Binary file 
./Programs/_testembed matches

and libpython3.10.a is in /usr/local/lib and /usr/local/lib/python3.10/config-3.10-x86_64-linux-gnu

$ find /usr/local/lib -name libpython3.10.a
/usr/local/lib/libpython3.10.a
/usr/local/lib/python3.10/config-3.10-x86_64-linux-gnu/libpython3.10.a

I'm not sure how mod_wsgi in the virtual environment should be set up to find the missing library file.

What other debugging steps should I take?

Note I also posted to https://groups.google.com/g/modwsgi about a week ago but didn't see any responses.

CodePudding user response:

This was answered in https://groups.google.com/g/modwsgi/c/KZZQHpFclGA/m/9St6XuSRAAAJ

Essentially, the problem is that python is using a different openssl than apache.

  • Related