ok, great! like this it now seems to work properly:



[eyoups@18fd7fd781bf ~]$ cat envvars

LD_LIBRARY_PATH=/eeups/eups/packages/Linux64/modWSGI/4.5.7+0/lib/python2.7/site-packages/mod_wsgi_httpd-2.4.23.1-py2.7-linux-x86_64.egg/mod_wsgi_packages/httpd/lib

export LD_LIBRARY_PATH

[eyoups@18fd7fd781bf ~]$ mod_wsgi-express start-server --envvars-script 
envvars

Server URL         : http://localhost:8000/

Server Root        : /tmp/mod_wsgi-localhost:8000:1000

Server Conf        : /tmp/mod_wsgi-localhost:8000:1000/httpd.conf

Error Log File     : /tmp/mod_wsgi-localhost:8000:1000/error_log (warn)

Environ Variables  : /home/eyoups/envvars

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


[eyoups@18fd7fd781bf ~]$ ls -la /tmp/mod_wsgi-localhost\:8000\:1000/

total 60

drwxr-xr-x 4 eyoups users  4096 Dec  8 07:51 
<http://airmail.calendar/2016-12-08%2007:51:00%20GMT+1> .

drwxrwxrwt 9 root   root   4096 Dec  7 14:02 
<http://airmail.calendar/2016-12-07%2014:02:00%20GMT+1> ..

-rwxr-xr-x 1 eyoups users  2898 Dec  8 07:51 
<http://airmail.calendar/2016-12-08%2007:51:00%20GMT+1> apachectl

-rw-r--r-- 1 eyoups users  1007 Dec  8 07:51 
<http://airmail.calendar/2016-12-08%2007:51:00%20GMT+1> default.wsgi

-rw-r--r-- 1 eyoups users    24 Dec 
<http://airmail.calendar/2016-12-24%2012:00:00%20GMT+1>  8 07:51 
<http://airmail.calendar/2016-12-12%2007:51:00%20GMT+1> envvars

-rw-r--r-- 1 eyoups users   210 Dec  8 07:51 
<http://airmail.calendar/2016-12-08%2007:51:00%20GMT+1> error_log

-rw-r--r-- 1 eyoups users  2973 Dec  8 07:51 
<http://airmail.calendar/2016-12-08%2007:51:00%20GMT+1> handler.wsgi

drwxr-xr-x 2 eyoups users  4096 Dec  7 14:02 
<http://airmail.calendar/2016-12-07%2014:02:00%20GMT+1> htdocs

-rw-r--r-- 1 eyoups users 17321 Dec  8 07:51 
<http://airmail.calendar/2016-12-08%2007:51:00%20GMT+1> httpd.conf

drwxr-xr-x 2 eyoups users  4096 Dec  7 14:02 
<http://airmail.calendar/2016-12-07%2014:02:00%20GMT+1> python-eggs

-rw-r--r-- 1 eyoups users   180 Dec  8 07:51 
<http://airmail.calendar/2016-12-08%2007:51:00%20GMT+1> resource.wsgi

-rw-r--r-- 1 eyoups users     0 Dec  7 14:02 
<http://airmail.calendar/2016-12-07%2014:02:00%20GMT+1> rewrite.conf



how can I now set LD_LIBRARY_PATH by default?


thanks!

michael





On Thursday, December 8, 2016 at 8:45:15 AM UTC+1, Graham Dumpleton wrote:
>
> If you aren’t moving stuff after being installed, then it shouldn’t be 
> needed. It should go to that directory anyway.
>
> That you have those libraries in system lib still may be confusing things 
> though.
>
> As a first test, create a file called ‘envvars’. Add to it:
>
>   
>   
> LD_LIBRARY_PATH=/eeups/eups/packages/Linux64/modWSGI/4.5.7+0/lib/python2.7/site-packages/mod_wsgi_httpd-2.4.23.1-py2.7-linux-x86_64.egg/mod_wsgi_packages/httpd/lib
>     export LD_LIBRARY_PATH
>
> Make sure that directories does have the libraries in it and I haven’t got 
> it wrong.
>
> Then run mod_wsgi-express as:
>
>     mod_wsgi-express start-server --envars-script envvars
>
> See if that works.
>
> Graham
>
> On 8 Dec 2016, at 6:40 PM, Michael Graber <[email protected] 
> <javascript:>> wrote:
>
>
> By installing I mean running the entire build script from scratch. There 
> are no ‘precompiled' files moved.
>
> Does the LD_LIBRARY_PATH need to be set in the build instructions, before 
> installing mod_wsgi, after the mod_wsgi-httpd installation has been 
> completed?
>
>
>
>
> On 8 December 2016 at 08:31:26, Graham Dumpleton ([email protected] 
> <javascript:>) wrote:
>
> Two issues.
>
> By installing it at a different directory, finding of shared libraries for 
> Apache will be broken as can’t rely on the path embedded in the executables.
>
> You have the system packages for APR and PCRE installed on the system, so 
> those are being found instead of the desired ones.
>
> You would likely need to set LD_LIBRARY_PATH environment variable to:
>
>     
> LD_LIBRARY_PATH=/eeups/eups/packages/Linux64/modWSGI/4.5.7+0/lib/python2.7/site-packages/mod_wsgi_httpd-2.4.23.1-py2.7-linux-x86_64.egg/mod_wsgi_packages/httpd/lib
>
> That way will look in directory where the shared libraries for the custom 
> Apache are located.
>
> Graham
>
> On 8 Dec 2016, at 6:27 PM, Michael Graber <[email protected] 
> <javascript:>> wrote:
>
>
> I installed mod_wsgi inside a docker container. Do do so I used our 
> package management system, like any other user in our collaboration could 
> do, directly on his/her machine.
>
> The path where the packages go is configurable by the user. In the case of 
> the docker container we chose it to be /eeups/eups/packages/ ..
>
> Here is what you asked me to figure out:
>
>
> [eyoups@18fd7fd781bf ~]$ ldd 
> /eeups/eups/packages/Linux64/modWSGI/4.5.7+0/lib/python2.7/site-packages/mod_wsgi_httpd-2.4.23.1-py2.7-linux-x86_64.egg/mod_wsgi_packages/httpd/bin/httpd
> linux-vdso.so.1 =>  (0x00007ffdaa2fc000)
> libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fa1ab212000)
> libaprutil-1.so.0 => /lib64/libaprutil-1.so.0 (0x00007fa1aafe8000)
> libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fa1aadbe000)
> libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007fa1aab8f000)
> librt.so.1 => /lib64/librt.so.1 (0x00007fa1aa986000)
> libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fa1aa74f000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa1aa533000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007fa1aa32e000)
> libc.so.6 => /lib64/libc.so.6 (0x00007fa1a9f6c000)
> libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fa1a9d67000)
> libdb-5.3.so => /lib64/libdb-5.3.so (0x00007fa1a99a8000)
> /lib64/ld-linux-x86-64.so.2 (0x00005570756a1000)
> libfreebl3.so => /lib64/libfreebl3.so (0x00007fa1a97a5000)
>
>
> Thanks,
> Michael
>
>
>
>
> On 8 December 2016 at 00:20:52, Graham Dumpleton ([email protected] 
> <javascript:>) wrote:
>
> Are you changing the location of where it gets installed when inside of 
> the docker container?
>
> What do you get for:
>
>     ldd 
> /eeups/eups/packages/Linux64/modWSGI/4.5.7+0/lib/python2.7/site-packages/mod_wsgi_httpd-2.4.23.1-py2.7-linux-x86_64.egg/mod_wsgi_packages/httpd/bin/httpd
>
> Graham
>
> On 8 Dec 2016, at 1:08 AM, Michael Graber <[email protected] 
> <javascript:>> wrote:
>
>
> ok, i added the re.escape(prefix) command into the setup.py of 
> mod_wsgi-httpd.
>
> now it compiles! great! thanks for your support Graham!
>
>
> .. however, if I now use our package management system to install mod_wsgi 
> including mod_wsgi-httpd inside a docker container (centos7 base image) 
> everything installs properly, BUT if i test the installation with
>
> $ mod_wsgi-express start-server
>
> i still get an error:
>
> [eyoups@18fd7fd781bf tmp]$ mod_wsgi-express start-server
> Server URL         : http://localhost:8000/
> Server Root        : /tmp/mod_wsgi-localhost:8000:1000
> Server Conf        : /tmp/mod_wsgi-localhost:8000:1000/httpd.conf
> Error Log File     : /tmp/mod_wsgi-localhost:8000:1000/error_log (warn)
> 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
> httpd (mod_wsgi-express)  : Syntax error on line 50 of 
> /tmp/mod_wsgi-localhost:8000:1000/httpd.conf: Cannot load 
> /eeups/eups/packages/Linux64/modWSGI/4.5.7+0/lib/python2.7/site-packages/mod_wsgi_httpd-2.4.23.1-py2.7-linux-x86_64.egg/mod_wsgi_packages/httpd/modules/mod_mpm_event.so
>  
> into server: 
> /eeups/eups/packages/Linux64/modWSGI/4.5.7+0/lib/python2.7/site-packages/mod_wsgi_httpd-2.4.23.1-py2.7-linux-x86_64.egg/mod_wsgi_packages/httpd/modules/mod_mpm_event.so:
>  
> undefined symbol: apr_skiplist_insert
>
>
> sorry, to keep bothering you, but I feel like we’re very close to a 
> working system .. and this is still a bit too cryptic for me.
>
> Thanks,
> Michael
>
>
>
>
>
>
>
>
>
> On 7 December 2016 at 12:06:19, Michael Graber ([email protected] 
> <javascript:>) wrote:
>
>
>
> ok, thanks Graham for staying up!
>
> I’ll see how far I can get and I’ll keep you posted ..
>
> Thanks again,
> Michael
>
>
>
>
> ------------------------------------------------------------------------
> Michael Graber, PhD
> [email protected] <javascript:>
>
> On 7 December 2016 at 12:03:56, Graham Dumpleton ([email protected] 
> <javascript:>) wrote:
>
>
> On 7 Dec 2016, at 9:58 PM, Michael Graber <[email protected] 
> <javascript:>> wrote:
>
> ok, I’m running now builds with the which-commands removed ..
>
> I understand you suspect the ‘+’ in the path to be a source of problems.
>
> Would you like me to try this out by changing the setup.py file?
>
>
> Yes please, if you can.
>
> I have already confirmed that the ‘+’ in the path is the cause of the 
> issues and making the change to setup.py fixes it.
>
> I have now:
>
>     with open('build/httpd/build/config_vars.mk') as fpin:
>         config_vars = fpin.readlines()
>
>     with open('build/httpd/build/config_vars.mk', 'w') as fpout:
>         prefix = os.path.join(os.getcwd(), 'build/httpd')
>         for line in config_vars:
>             line = re.sub(re.escape(prefix), '${mod_wsgi_httpd_prefix}', 
> line)
>             print(line, end='', file=fpout)
>
> With the re.escape(prefix) in there.
>
> I will release an updated package tomorrow. Is getting late here now,
>
> Graham
>
> On 7 December 2016 at 11:52:32, Graham Dumpleton ([email protected] 
> <javascript:>) wrote:
>
> That doesn’t matter. It doesn’t need ‘apxs’. That was debugging line to 
> make sure you didn’t have an ‘apxs’ from Apache from somewhere else on your 
> system. Take out ‘which apxs’.
>
> Anyway, catch up with my other emails first and will see am closer 
> possible issue. :-)
>
> Graham
>
> On 7 Dec 2016, at 9:50 PM, Michael Graber <[email protected] 
> <javascript:>> wrote:
>
>
> Thanks for digging into this with me!
>
> You suggested a couple of things.
>
> I removed the CFLAGS and and PATH appending.
>
> Now the build crashes because it does not find apxs anymore. From the 
> build log:
>
> + which apxs
> which: no apxs in 
> (/des002/devel/eeups/ci_build_desbuild/Linux64/modWSGI/4.5.7+0/bin:/des002/devel/eeups/ci_build_desbuild/Linux64/modWSGIhttpd/2.4.23.1+0/bin:/des002/devel/eeups/ci_build_desbuild/Linux64/tcl/8.5.17+0/bin:/des002/devel/eeups/ci_build_desbuild/Linux64/tk/8.5.17+1/bin:/des002/devel/eeups/ci_build_desbuild/Linux64/sqlite/3080002+0/bin:/des002/devel/eeups/ci_build_desbuild/Linux64/python/2.7.9+1/bin:/usr/local/bin:/bin:/usr/bin:/des002/devel/eeups/eups_desbuild/1.2.30/bin)
>
>
>
> entire log still at 
> http://desbuild.cosmology.illinois.edu/eeups/webservice/dashboard/products/modWSGI/4.5.7%2B0/desbuild/build/build.log
>
> digging further ..
>
>
>
> On Wednesday, December 7, 2016 at 11:23:42 AM UTC+1, Graham Dumpleton 
> wrote:
>>
>> What is the contents of:
>>
>> ${PRODUCT_DIR}/lib/python2.7/site-packages/mod_wsgi_httpd-2.4.23.1-py2.7-linux-x86_64.egg/mod_wsgi_packages/httpd/build/config_vars.mk
>>
>>
>> On 7 Dec 2016, at 9:14 PM, Graham Dumpleton <[email protected]> 
>> wrote:
>>
>> These should also not be required:
>>
>>      export 
>> CFLAGS="-I${PRODUCT_DIR}/lib/python2.7/site-packages/mod_wsgi_httpd-2.4.23.1-py2.7-linux-x86_64.egg/mod_wsgi_packages/httpd/include"
>>         export CFLAGS="$CFLAGS 
>> -I${PRODUCT_DIR}/lib/python2.7/site-packages/mod_wsgi_httpd-2.4.23.1-py2.7-linux-x86_64.egg/mod_wsgi_packages/httpd/include/apr-1"
>>
>>
>> Graham
>>
>> On 7 Dec 2016, at 9:10 PM, Graham Dumpleton <graham.d...@<a href="
>> http://gmail
>>
>>

-- 
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.

Reply via email to