Some good news! I got the system to work! More by accident than deliberate problem-solving. But before I get to the 'fix', let me answer your questions,
On Monday, May 23, 2016 at 3:57:39 PM UTC+5:30, Graham Dumpleton wrote: > > What do you get when you run: > > > ldd /srv/VENVs/bottle/lib/python2.7/site-packages/_xmlplus/parsers/pyexpat.so > > and: > > ldd /usr/local/apache2/bin/httpd > > [vagrant@bottle httpd]$ ldd /srv/VENVs/bottle/lib/python2.7/site-packages/ _xmlplus/parsers/pyexpat.so linux-vdso.so.1 => (0x00007ffc723f1000) libpython2.7.so.1.0 => /opt/oss_sources/Python-2.7.11/../COMPILED_PYTHON/ lib/libpython2.7.so.1.0 (0x00007f05298ae000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f052968b000) libc.so.6 => /lib64/libc.so.6 (0x00007f05292f7000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f05290f3000) libutil.so.1 => /lib64/libutil.so.1 (0x00007f0528eef000) libm.so.6 => /lib64/libm.so.6 (0x00007f0528c6b000) /lib64/ld-linux-x86-64.so.2 (0x00007f0529ecd000) [vagrant@bottle httpd]$ [vagrant@bottle httpd]$ ldd /usr/local/apache2/bin/httpd linux-vdso.so.1 => (0x00007fff00720000) libpcre.so.0 => /lib64/libpcre.so.0 (0x00007fe6871d2000) libaprutil-1.so.0 => /usr/local/apache2/lib/libaprutil-1.so.0 ( 0x00007fe686fac000) libexpat.so.0 => /usr/local/apache2/lib/libexpat.so.0 (0x00007fe686d85000) libapr-1.so.0 => /usr/local/apache2/lib/libapr-1.so.0 (0x00007fe686b52000) librt.so.1 => /lib64/librt.so.1 (0x00007fe686949000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fe686712000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe6864f5000) libc.so.6 => /lib64/libc.so.6 (0x00007fe686160000) /lib64/ld-linux-x86-64.so.2 (0x00007fe687405000) libfreebl3.so => /lib64/libfreebl3.so (0x00007fe685f5d000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fe685d58000) [vagrant@bottle httpd]$ An overly simplified view of my provisioning script is as follows, 1. Update centos6 packages (this is NOT upgrading to centos7, just individual package updates) 2. Download python2.7 sources, compile and install 3. Download httpd sources, compile and install 4. Download mod_wsgi sources, compile and install 5. Clone my project repository to local file-system 6. Copy over different config files and restart httpd service What you need to realize is that none of the above steps displayed any error message to me. They all seemed to flow just fine. Today afternoon, in an effort to get more debugging information, I updated the provisioning steps to compile debug versions of ALL the OSS sources I use - python, apache and mod_wsgi. Also included the expat-devel package from the yum repositories. At first I was shocked to discover that the debug builds did not produce any segmentation faults. Eventually I narrowed down the cause to the missing expat-devel package. Graham, I'm really grateful to you for helping me out. If you hadn't commented about something funny in expat, I would have never figured this out. *Thank you!* :) On a different note, any idea what could explain this behavior? My experience with *nix-based utilities is that if you don't have an underlying dependency installed, the utility will throw an error or attempt to resolve the dependency itself. This is the first time I'm seeing something proceed without issues through both compilation and installation, but only to fail at run-time. Puzzled, Abraham V. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
