mod_wsgi-express in Canopy: failing to load @rpath/Python

[SGaffney]

Hello,

I'm struggling with installation of mod_wsgi-express in my Canopy distribution. Compilation works fine (output from python setup.py install is attached), but when I run `mod_wsgi-express start-server`, I get the error "Library not loaded: @rpath/Python" (follows email).

From related support posts, I see that setting the LD_RUN_PATH at compilation is crucial, but the setup.py file seems to get mine right:

[from debugger inspection in setup.py before "# Now finally run distutils."]

>> LD_RUN_PATH

'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib:/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/config'

>> PYTHON_LDFLAGS

['-L/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib', '-L/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/config']

>> PYTHON_LDLIBS

['-lpython2.7']

And here's the output of ldd on the .so file:

> ldd mod_wsgi-py27.so

@rpath/Python (compatibility version 2.7.0, current version 2.7.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

I'd be very grateful for any suggestions.

Thank you,

Stephen

-------

$ mod_wsgi-express start-server

Server URL         : http://localhost:8000/

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

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

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

Request Capacity   : 5 (1 process * 5 threads)

Request Timeout    : 60 (seconds)

Queue Backlog      : 100 (connections)

Queue Timeout      : 45 (seconds)

Server Capacity    : 20 (event/worker), 20 (prefork)

Server Backlog     : 500 (connections)

Locale Setting     : en_GB.UTF-8

httpd (mod_wsgi-express) : Syntax error on line 151 of /tmp/mod_wsgi-localhost:8000:502/httpd.conf: Cannot load /Users/sgg/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/mod_wsgi-4.5.1-py2.7-macosx-10.6-x86_64.egg/mod_wsgi/server/mod_wsgi-py27.so into server: dlopen(/Users/sgg/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/mod_wsgi-4.5.1-py2.7-macosx-10.6-x86_64.egg/mod_wsgi/server/mod_wsgi-py27.so, 10): Library not loaded: @rpath/Python\n  Referenced from: /Users/sgg/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/mod_wsgi-4.5.1-py2.7-macosx-10.6-x86_64.egg/mod_wsgi/server/mod_wsgi-py27.so\n  Reason: image not found

[Graham Dumpleton]

Are you really running MacOS X 10.6?

This issue used to come up in old MacOS X versions.

The problem is that one of Apache, mod_wsgi or the Python library doesn’t have a binary image in it for the required architecture. That is, 32 bit or 64 bit.

What do you get when you run:

    file mod_wsgi-py27.so

    file /usr/sbin/httpd

    file /Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/libpython2.7.so

You may have to work out the correct path for each of these.

There was some notes about related issue in really old documentation on old Google Code site about things like this.

    https://code.google.com/archive/p/modwsgi/wikis/InstallationOnMacOSX.wiki

Graham

--
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 modwsgi+u...@googlegroups.com.
To post to this group, send email to mod...@googlegroups.com.
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
<setup.py_install_output.txt>

[Graham Dumpleton]

Actually this could just be it not even finding the Python framework. On older MacOS X versions it wasn’t uncommon for third party Python installations to screw things up so that it wasn’t actually possible to link to their framework from a separate application.

All the LD_RUN_PATH is not used on MacOS X. That is Linux or Solaris.

I can’t remember how to you fix up the framework reference in mod_wsgi.so if it is broken.

I don’t think you can simply set the environment variable:

  DYLD_LIBRARY_PATH=/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib

when running mod_wsgi-express.

That doesn’t seem to be the correct directory for where the framework library might be installed anyway.

What do you get for:

    find /Applications/Canopy.app -name Python -print

Graham

[SGaffney]

Thank you for the very fast response—excuse my slowness, caused by not setting up email alerts properly.

Starting with last question first, the Python library/executable files:

1. Python / 'libpython2.7.so'

======================

$ find /Applications/Canopy.app -name Python -print

1. /Applications/Canopy.app/Contents/Python
   
2. /Applications/Canopy.app/Contents/Resources/Python.app/Contents/MacOS/Python
   
3. /Applications/Canopy.app/Contents/Resources/PythonNoDock.app/Contents/MacOS/Python
   
4. /Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/Python
   
5. /Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/Resources/Python.app/Contents/MacOS/Python
   
6. /Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/Resources/PythonNoDock.app/Contents/MacOS/Python

*items 1,4: Mach-O 64-bit dynamically linked shared library x86_64

*items 2,3,5,6: Mach-O 64-bit executable x86_64

Item 1 is the source file for the following symlinks:

•     ~/Library/Enthought//Canopy_64bit/User/Python
  
•     ~/Library/Enthought//Canopy_64bit/System/Python
  
•     ~/Library/Enthought//Canopy_64bit/User/lib/libpython2.7.dylib
  
•     ~/Library/Enthought//Canopy_64bit/System/lib/libpython2.7.dylib
  

Item 1 otool output:

    Mach header

          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags

    MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    12       1656   NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS

4 additional 'Python' executables in ~

--------------------------------------------------

• ~/Library/Enthought//Canopy_64bit/User/Resources/Python.app/Contents/MacOS/Python
  
• ~/Library/Enthought//Canopy_64bit/System/Resources/Python.app/Contents/MacOS/Python
  
• ~/Library/Enthought//Canopy_64bit/User/Resources/PythonNoDock.app/Contents/MacOS/Python
  
• ~/Library/Enthought//Canopy_64bit/System/Resources/PythonNoDock.app/Contents/MacOS/Python
  

* all Mach-O 64-bit executable x86_64

2. SDKs

=======

My mac (OSX 10.11) has 3 SDKs installed after multiple OS X and XCode updates:

• /Developer/SDKs/MacOSX10.5.sdk/
  
• /Developer/SDKs/MacOSX10.6.sdk.hide/
  
• /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/bin/apr-1-config
  

Note the '.hide' appended to the 10.6 SDK. Compilation of mod_wsgi-express didn't work until I did that. 10.6 is only there in response to an earlier Canopy issue. I installed it in Mavericks after seeing this Canopy support post.

3. Canopy lib folders

================

$ tree /Applications/Canopy.app/Contents/lib/

/Applications/Canopy.app/Contents/lib/

└── python2.7

    ├── config

    │   ├── Makefile

    │   ├── Setup

    │   ├── Setup.config

    │   ├── Setup.local

    │   ├── config.c

    │   ├── config.c.in

    │   ├── enthought.dat

    │   ├── install-sh

    │   ├── libpython2.7.a

    │   ├── libpython2.7.dylib

    │   ├── makesetup

    │   └── python.o

    ├── lib-dynload

    │   └── fcntl.so

    ├── os.py

    └── site.py

Other lib directories in Canopy default virtual environments.

• ~/Library/Enthought/Canopy_64bit//System/lib
  
• ~/Library/Enthought/Canopy_64bit//User/lib
  

4. httpd

======

$ file /usr/sbin/httpd

/usr/sbin/httpd: Mach-O 64-bit executable x86_64

5. mod-wsgi-py27.so

=================

• path: ~/Library/Enthought/Canopy_64bit/User//lib/python2.7/site-packages/mod_wsgi-4.5.1-py2.7-macosx-10.6-x86_64.egg/mod_wsgi/server/mod_wsgi-py27.so
  
• size: 241Kb
  
• file: Mach-O 64-bit bundle x86_64
  
• otool:
  

      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags

MH_MAGIC_64  X86_64        ALL  0x00      BUNDLE    13       1672   NOUNDEFS DYLDLINK TWOLEVEL

6. *-config files

===========

python2.7-config

----------------------

• /usr/bin/python2.7-config
  
• /System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
  
• /Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/bin/python2.7-config
  
• ~/Library/Enthought/Canopy_64bit/System/bin/python2.7-config
  
• ~/Library/Enthought/Canopy_64bit/User/bin/python2.7-config

apr-1-config

----------------

• /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/bin/apr-1-config
  
• /Developer/SDKs/MacOSX10.5.sdk/usr/bin/apr-1-config
  
• /Developer/SDKs/MacOSX10.6.sdk.hide/usr/bin/apr-1-config
  
• /usr/bin/apr-1-config
  
• /usr/local/Library/ENV/4.3/apr-1-config
  

Thanks for your time and for any further pointers,

Stephen

[Graham Dumpleton]

Rather than using the ‘pip’ installable mod_wsgi, you might want to try older way of building it from source code.

Grab down latest source tar ball from:

    https://github.com/GrahamDumpleton/mod_wsgi/releases

When unpacked, build it using:

    ./configure —with-python=/some/path/to/canopy/bin/python

    make

Before trying to install it, run:

    otool -L src/server/.libs/mod_wsgi.so

If that doesn’t show the Python library resolving, try instead:

    make distclean

    ./configure —with-python=/some/path/to/canopy/bin/python --enable-framework

    make

Run otool again. Does that then show it as resolving?

Graham

[Stephen Gaffney]

Thank you, yes: using both the --with-python and --enable-framework flags were necessary to resolve the Python library (albeit to the system Python library, but perhaps that doesn't matter?).

otool output without --enable-framework:

    @rpath/Python (compatibility version 2.7.0, current version 2.7.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1258.1.0)

​

otool output with --enable-framework:

    /System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.10)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1258.1.0)

​

Incidentally, otool shows the @rpath/Python line for the various Canopy 'Python' library files.

    @rpath/Python (compatibility version 2.7.0, current version 2.7.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

Back to mod_wsgi-express, I found that using install_name_tool to add a Canopy directory containing 'Python' prevents the 'image not found' error. (Other errors crop up in the log file though, attached.)

install_name_tool -add_rpath $HOME/Library/Enthought/Canopy_64bit/User/ \
$HOME/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/mod_wsgi-4.5.2-py2.7-macosx-10.6-x86_64.egg/mod_wsgi/server/mod_wsgi-py27.so

​

I'm happy to go without mod_wsgi-express, but if it's at all helpful to you to get to the bottom of Canopy issues, I'm happy to try other things.

Thanks a lot for your help.

Stephen

--
You received this message because you are subscribed to a topic in the Google Groups "modwsgi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/modwsgi/liw8DqjK1XA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to modwsgi+u...@googlegroups.com.

[Graham Dumpleton]

Using install_name_tool was why I asked previously about where ‘Python’ was located. :-)

It was in so many locations that thought would try the traditional build first.

I don’t have time to look at separate log right this minute, but can you send me from the Makefile generated when doing the —enable-framework what the various CFLAGS, LDFLAGS, LDLIBS variables in the Makefile were.

The problem with it still picking up the wrong framework in that case has been an issue years ago on older MacOS X and as far as known was because the Python installations were broken in the way they setup framework linking. Never did find the exact reason and switching to the -L/-l style linking instead of framework linking fixed it, and why that is now the default. For you though that doesn’t work. :-(

Thanks.

Graham

<error_log.txt>

[Stephen Gaffney]

Here are the Makefile variables:

CPPFLAGS =  -I/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/include/python2.7 -DNDEBUG 
CFLAGS =  -Wc,-g -Wc,-O2  -Wc,'-arch x86_64'
LDFLAGS =  -Wl,-F/Library/Frameworks -framework Python -u _PyMac_Error EPD64.framework/Versions/2.1.0.dev1829/Python  -arch x86_64
LDLIBS =  -ldl  -framework CoreFoundation

​

I'll try a fresh Canopy installation on a separate OS X 10.11 machine in case there's something funny about my setup.

Thanks,

Stephen

[Graham Dumpleton]

On 15 Apr 2016, at 10:30 PM, Stephen Gaffney <sgga...@gmail.com> wrote:

Here are the Makefile variables:

CPPFLAGS =  -I/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/include/python2.7 -DNDEBUG 
CFLAGS =  -Wc,-g -Wc,-O2  -Wc,'-arch x86_64'
LDFLAGS =  -Wl,-F/Library/Frameworks -framework Python -u _PyMac_Error EPD64.framework/Versions/2.1.0.dev1829/Python  -arch x86_64
LDLIBS =  -ldl  -framework CoreFoundation

I'll try a fresh Canopy installation on a separate OS X 10.11 machine in case there's something funny about my setup.

Don’t think there is a point. Their internal configuration that is cached from the original build of Python is broken. So they obviously do stupid things when they build their distro.

Change the LDFLAGS line to:

    LDFLAGS = -Wl,-F$HOME/Library/Enthought/Canopy_64bit/User -framework Python -u _PyMac_Error -arch x86_64

Substitute the actual value for $HOME.

Then go:

    make clean

    make

and run ‘otool -L’ again on the mod_wsgi.so file.

Also, can you send me the generated httpd.conf file that mod_wsgi-express creates. This will be at the location shown when mod_wsgi-express is run.

I want to verify what WSGIPythonHome directive is set to in that, but there may be other information I can glean from it as well.

Thanks.

Graham

Thanks,

Stephen

On Fri, Apr 15, 2016 at 1:12 PM, Graham Dumpleton <graham.d...@gmail.com> wrote:

Using install_name_tool was why I asked previously about where ‘Python’ was located. :-)

It was in so many locations that thought would try the traditional build first.

I don’t have time to look at separate log right this minute, but can you send me from the Makefile generated when doing the —enable-framework what the various CFLAGS, LDFLAGS, LDLIBS variables in the Makefile were.

The problem with it still picking up the wrong framework in that case has been an issue years ago on older MacOS X and as far as known was because the Python installations were broken in the way they setup framework linking. Never did find the exact reason and switching to the -L/-l style linking instead of framework linking fixed it, and why that is now the default. For you though that doesn’t work. :-(

Thanks.

Graham

[Stephen Gaffney]

I changed the LDFLAGS as suggested and got the following otool output for mod_wsgi.so.

    /System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.10)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1258.1.0)

​

(I had to specify LIBEXECDIR=... on the make install line to not get what looks like a System Integrity Protection error.)

I've attached the httpd.conf file from the install_name_tool-tweaked 'setup.py install' attempt.

--
You received this message because you are subscribed to a topic in the Google Groups "modwsgi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/modwsgi/liw8DqjK1XA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to modwsgi+u...@googlegroups.com.

[Graham Dumpleton]

I really hate these third party Python distributions. Don’t know what they do to break framework linking.

Even using the install_name_tool tweak, the Python distribution is ignoring the WSGIPythonHome directive, presuming that the argument to that is the same as sys.prefix you get for that Python when run from command line.

That directive should be triggering a Python C API call of Py_SetPythonHome() which sets the PYTHONHOME. What it is given should be used unless they have mucked around with the Python initialisation sequence.

What do you get if you set:

export PYTHONHOME=$HOME/Library/Enthought/Canopy_64bit/User

before running mod_wsgi-express.

Presuming again that is the value of sys.prefix.

BTW, what is the reason you aren’t just using the system Python version?

Graham

<httpd.conf>

[SGaffney]

I'm very hesistant to take up more of your time on this problem, since installing straight into Apache works fine and it's not essential that I use Canopy. So don't persist for my sake, but I'm happy to keep testing things if you think it's worth getting to the bottom of. (I've ended up with Canopy through historical accident, as that's how I was introduced to Python, and have a couple of web apps that are using Canopy virtual environments. I'm now reconsidering this setup.)

The WSGIPythonHome directive is indeed the same as the sys.prefix (~/Library/Enthought/Canopy_64bit/User).

When I set the environment variable PYTHONHOME to this path, python won't start at all: I get the error "ImportError: No module named site". This is not the case when I set PYTHONHOME to /Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/

Where I can get mod_wsgi-express to start (either by not setting PYTHONHOME or by setting it to the path above), I get an error when an import of mod_wsgi.server is attempted in handler.wsgi. The log file says "ImportError: No module named server".

If I print out sys.path before this import statement, I see the following:

['/private/tmp/mod_wsgi-localhost:8000:502'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python27.zip'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/plat-darwin'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/plat-mac'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/plat-mac/lib-scriptpackages'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/lib-tk'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/lib-old'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/lib-dynload'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/site-packages']

​

At the risk of exposing my ignorance, I thought that modifying sys.path such that it matches what I'd normally see in Canopy might help, so with sys.path.insert() and sys.path.extend(), I updated sys.path before import to be:

['/private/tmp/mod_wsgi-localhost:8000:502'
'/Users/sgg/Library/Enthought/Canopy_64bit/User/bin'
'/Users/sgg/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/mod_wsgi-4.5.2-py2.7-macosx-10.6-x86_64.egg'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python27.zip'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/plat-darwin'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/plat-mac'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/plat-mac/lib-scriptpackages'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/lib-tk'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/lib-old'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/lib-dynload'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/site-packages'
'/Users/sgg/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages'
'/Applications/Canopy.app/appdata/canopy-1.6.2.3262.macosx-x86_64/Canopy.app/Contents/lib/python2.7/site-packages'
'/Users/sgg/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/IPython/extensions'
'/Users/sgg/.ipython']

​

...but I get the same import error. The third path in that list is where mod_wsgi is installed.

tree -d ~/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/mod_wsgi-4.5.2-py2.7-macosx-10.6-x86_64.egg

├── EGG-INFO

└── mod_wsgi

    ├── docs

    ├── images

    └── server

        └── management

            └── commands

In the past, I've found it necessary to add sys.path.insert(1, '<virtual_environment_dir>/lib/python2.7/site-packages')) to my wsgi files, but this hasn't helped here.

Thanks,

Stephen