> On 24 May 2016, at 2:05 AM, 'Abraham Varricatt' via modwsgi > <[email protected]> wrote: > > 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.
Because you compile Apache from source code, there was nothing to trigger installation of expat-devel. The result was that Apache build couldn’t find it and so used its own internal copy. libexpat.so.0 => /usr/local/apache2/lib/libexpat.so.0 (0x00007fe686d85000) When pyexpat.so was built, it also used its own copy, but the problem may be that when using its own copy, it doesn’t namespace prefix symbols so they will not clash with a proper libexpat.so linked in by something else. This used to be an issue with the expat module in Python itself until they started namespace prefixing their own version. I don’t understand why the one in the libXML package hasn’t learnt from that. At least that appears to be what occurred. After you install expat-devel and rebuild everything, does pyexpat.so then link to system libexpat.so? Graham > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
