New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PySide in relocatable virtualenv: Library not loaded: @rpath/libpyside-python2.7.1.2.dylib #129
Comments
I made PySide work inside a relocatable virtualenv on OS X 10.11 (El Capitan). I modified the I don't know if you think this is a proper fix/workaround for OS X? def localize_libpaths(libpath, local_libs, enc_path=None):
""" Set rpaths and install names to load local dynamic libs at run time
Use ``install_name_tool`` to set relative install names in `libpath` (as
named in `local_libs` to be relative to `enc_path`. The default for
`enc_path` is the directory containing `libpath`.
Parameters
----------
libpath : str
path to library for which to set install names and rpaths
local_libs : sequence of str
library (install) names that should be considered relative paths
enc_path : str, optional
path that does or will contain the `libpath` library, and to which the
`local_libs` are relative. Defaults to current directory containing
`libpath`.
"""
if enc_path is None:
enc_path = abspath(dirname(libpath))
install_names = osx_get_install_names(libpath)
need_rpath = False
for install_name in install_names:
if install_name[0] in '/@':
continue
if hasattr(sys, 'real_prefix'):
# virtualenv detected - use @executable_path
back_tick('install_name_tool -change %s @executable_path/../lib/python2.7/site-packages/PySide/%s %s' %
(install_name, install_name, libpath))
else:
# not a virtualenv - use @rpath
back_tick('install_name_tool -change %s @rpath/%s %s' %
(install_name, install_name, libpath))
need_rpath = True
if need_rpath and enc_path not in osx_get_rpaths(libpath):
back_tick('install_name_tool -add_rpath %s %s' %
(enc_path, libpath)) |
Interesting, but did you use the latest version? Actually, I'm interested to use it on PySide2, that is the upcoming Qt5 version. |
Ah, you used version 1.2.2, because that for-loop from above has a bug, that I fixed in Pyide and PySide2. |
Ok, I'll give it a shot. Do you mean like this?
I'm actually getting this when cloning pyside-setup like that:
Any idea on how I should proceed? |
Oops, I just saw that I made a bad change, from the old gitorious submodules to github, but the modules were old ones from 2012. Will fix that, sorry |
Great, thanks. Let me know when it's ready. I'm calling it a day now :) |
By the way, I notice that another patch is needed to make PySide work properly in a relocatable virtualenv on Linux. I'm not sure if On Windows it all works as-is with no need for any patching. |
Ok, I think it is ready. Restored things with the help of PySide2. Then I had to search a while until I found out how to get rid of the Qt5 branches: I needed to also removed the tagging, then things finally vanished ;-) |
No idea about patchelf. I have to say that I always cared about OS X. Just since May, when I was forced to work with Windows and Linux on Qt5, but relocation was not my top priority. If you find a nice solution, I'm happy to try a PR. |
I just compiled on both OS X and Linux and there's no need for any patching with this 1.3.0dev version of PySide. PySide works just fine even after having moved around the virtualenv. Awesome! :) Is this 1.3.0dev version considered stable, or are you still fixing things and will release a true 1.3.0 later on? About patchelf, you're supposed to be able to use |
Fine to hear that, good that nothing was permanently damaged. But maybe you motivated me to push it a bit ;-) |
Hehe, yeah. PySide is actually the standard in my line of work (visual effects/3D animation for films/commercials/archviz) so lots of people are dependent on it. By the way, I was going to build 1.3.0dev from git on Windows 10, and I followed these instructions. I ran this command in a git cmd prompt:
However, I got this back:
The instructions doesn't say anything about Visual Studio 2008. Is it required or could I use something "lighter" than VS2008? |
Only Windows sdk is required R.
|
I did install Windows SDK 7 (on Windows 10), but it doesn't work using the command I posted, as you can see from the output: Also, I'm on Windows 10 with 64-bit Python 2.7.9. Maybe I need the Windows SDK 10 and/or some specials to compile using 64-bit Python? |
You can try to run the build from sdk command prompt
|
@fredrikaverpil btw., why are you using PySide and not PyQt? They have changed their licensing. Would be interesting to know (I just like PySide for a reason). |
@fredrikaverpil interesting. That somehow closes the circle, because I also tried to learn why Autodesk insisted in PySide2 for Qt5. Some things simply persist, because of kinda virtual dependency. I like that. |
@ctismer I wonder if maybe Autodesk originally went with PySide because of licensing reasons. And now that they have a rather large user base with PySide scripts running in their software they may want to keep on going with PySide2... Are you working with them on PySide2? I'm guessing that The Foundry also would like to have PySide2 bundled with Nuke since it comes with PySide today. Have you been in touch with The Foundry? By the way, will PySide2 be backwards-compatible with PySide? |
I can now also confirm that building from github source worked just fine in Windows too (thanks @lck for the reminder on using the proper CMD shell). I compiled for 64-bit and thus I needed Qt4 64-bit. Rather than building it myself from Qt4 v4.8.7, I used these Qt v4.8.4 64-bit precompiled binaries (qt-win64-opensource-4.8.4-noqt3-vs2008). Would you say this is wrong and that I should compile against Qt4 v4.8.7? – I'm not familiar enough with what aspects of Qt are used during PySide compile to judge whether this is fine or not. This was my build command:
Just like with PySide 1.2.2 there are no issues with relocating the virtualenv with PySide 1.3.0dev in it. To sum it up: I now have three PySide 1.3.0dev .whl files, one for each OS: Linux, OS X, Windows. They all install fine (pip) into a virtualenv and PySide still works properly after having moved the virtualenv around. So in a way, I guess we could close this issue, as the next release of PySide (probably tagged v1.2.3) will address this. The issue remains with PySide 1.2.2. |
No, I believe you are just fine with the pre-built build. Yes, the issue will be closed with 1.2.3, if the others agree. I guess the reluctance with tagging is that we than would have to build many binaries at once in no time, and that is always quite an undertaking. Should not be a problem with a build-bot. I think we will get one on PySide2. |
@fredrikaverpil I would like to get back to you with something in private emails. |
Sounds great! @ctismer sure, my email is fredrik.averpil@gmail.com |
Yes, 1.2.3 should be released soon. |
No, I have no idea what this is.
No, PySide2 is not backward compatible, and all the transitions apply. The transitions show only the tip of the iceberg - under the hood, the changes were even heavier, because PySide2 touches many internal things. |
Had this same issue with PySide 1.2.4. Installed via
If I fix the dynamic library path:
Then the |
@duozmo I'd recommend opening a new ticket to not lose the info. |
Can't reopen? |
@duozmo I can't. |
Does anyone know of a workaround for this issue? |
As long as Qt4 is installed (
However, not very elegant. |
@fredrikaverpil This solved a similar problem for my root environment. I was able to just add the equivalent line to my .bash_profile and the "Reason: image not found" issue was resolved. |
@duozmo your method fixed my problem. my environment is OS X 10.11.1 (15B42). |
@fredrikaverpil thanks, that solved my issue. |
@AwwCookies @shellyan @zzeleznick I would like to stress that I don't think this workaround is a proper one. You shouldn't need to set |
Hi guys, I'm still looking for a solution that doesn't include a workaround. Any ideas? still not working even with PySide 1.2.4. Same error:
|
+1 |
I'm having the same issue, i've applied the patch above and was able to get it working on my dev machine, but obviously it's not possible to run it of the network unless other machines have qt installed... |
So I ended up using Selenium with PhantomJS which is much better and -S. On Thu, Mar 10, 2016 at 9:08 AM, Mangosoft LLC notifications@github.com
|
So the good news is that a built a new wheel using the latest from the git repository... Unfortunately like Fred i'm developing apps for VFX which is standardized in PySide, plus allot of my applications are already written and working on windows.... Fred, how are handling the qt frame work? do you know of away of moving those DLL's to the virtualenv? |
I'm not. I'm currently installing it locally on each machine that needs PySide. 😠 You can build your own distribution of Qt from source and make the libraries load from within e.g. a virtualenv. The modifications needed to make the installation moveable is supposed to be mostly about library loading. The build system wants to add an install path and you'll need to not do that. You have to understand It really is a major issue. |
Running into this on OSX 10.11.4 and I'm running in a simple virtualenv like the others. |
Running into this on OSX 10.10.5. This is a problem because the PySide install docs don't work if you're using a virtualenv, which is surprising. $ brew install qt # stable 4.8.7
$ virtualenv env # defaults to 2.7.10 on Mac 10.10.5
$ . env/bin/activate
$ pip install -U PySide # ... takes a while
$ python -c 'from PySide import QtCore'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: dlopen(/Users/garrett/code/deprecated-binaryninja-python/env/lib/python2.7/site-packages/PySide/QtCore.so, 2): Library not loaded: @rpath/libpyside-python2.7.1.2.dylib
Referenced from: /Users/garrett/code/deprecated-binaryninja-python/env/lib/python2.7/site-packages/PySide/QtCore.so
Reason: image not found Can confirm that the workaround from #129 (comment) works for me as well, but I also agreed that such a workaround should not be necessary. |
I have this problem too, but I'm not in a virtualenv, just using a brew install'd python. |
+1 not using a virtualenv Installed qt with brew and PySide 1.2.4 w pip. Getting the exact same:
Updating the DYLD_LIBRARY_PATH did not help. |
same here on mac os x 10.11.6 |
The DYLD_LIBRARY_PATH didn't work for me. Using OS X 10.11.6. |
Luiz, It would be much appreciated :D |
Sure, I'm really busy today but I want to let you guys know what I did, On Fri, Oct 14, 2016 at 1:36 PM, Mangosoft LLC notifications@github.com
|
@luizgarrido much appreciated, looking forward to reading what you've been up to :) |
I didn't see an answer in this thread, so here's how I got PySide-1.2.4 working in a virtualenv on macOS Sierra. I'd installed qt via brew prior to this.
|
@nall nice, although that doesn't look like it offers relocation of the virtualenv, right? Edit: typo. |
Hm, I don't get the error anymore (I'm on El Capitan 10.11.6) and I can just use a relocatable venv out of the box: # Check system-installed packages
$ pip list
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
pip (9.0.1)
requests (2.12.1)
setuptools (28.8.0)
virtualenv (15.1.0)
wheel (0.29.0)
# Create "venv" virtualenv
$ virtualenv --always-copy venv
New python executable in /Users/fredrik/code/virtualenvs/venv/bin/python2.7
Also creating executable in /Users/fredrik/code/virtualenvs/venv/bin/python
Installing setuptools, pip, wheel...done.
# Check the packages of "venv"
$ venv/bin/pip list
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
pip (9.0.1)
setuptools (32.1.3)
wheel (0.29.0)
# Install PySide into "venv"
$ venv/bin/pip install pyside
Collecting pyside
Installing collected packages: pyside
Successfully installed pyside-1.2.4
# Attempt to import PySide (works fine)
$ venv/bin/python -c "from PySide import QtCore, QtGui, QtUiTools"
# Make virtualenv relocatable
$ virtualenv --relocatable venv
Making script /Users/fredrik/code/virtualenvs/venv/bin/easy_install relative
Making script /Users/fredrik/code/virtualenvs/venv/bin/easy_install-2.7 relative
Making script /Users/fredrik/code/virtualenvs/venv/bin/pip relative
Making script /Users/fredrik/code/virtualenvs/venv/bin/pip2 relative
Making script /Users/fredrik/code/virtualenvs/venv/bin/pip2.7 relative
Making script /Users/fredrik/code/virtualenvs/venv/bin/pyside-uic relative
Making script /Users/fredrik/code/virtualenvs/venv/bin/python-config relative
Making script /Users/fredrik/code/virtualenvs/venv/bin/wheel relative
# Move "venv"
$ mkdir some_new_path
$ mv venv some_new_path
$ cd some_new_path
$ mv venv moved_venv
# Attempt to import PySide in relocated virtualenv (works fine)
$ moved_venv/bin/python -c "from PySide import QtCore, QtGui, QtUiTools" |
I'm pip installing PySide into a virtualenv:
The virtualenv works great and I can run my Python/PySide script without problems:
Now, I make my virtualenv relocatable:
I move it:
...and again run my script:
This time around, I'm getting an error:
These are the contents of the script:
Please note: the absolute path printed twice in the error message is the $VENV_RELOCATED
This is all on OS X 10.11.0 with Python 2.7.10 and PySide 1.2.2.
Any ideas on workaround so that the virtualenv could be moved around?
The text was updated successfully, but these errors were encountered: