I am trying to setup a environment using conda.
My environemnt.yml looks like:
name: name
channels:
- defaults
- conda-forge
- pytorch
# - fastai
dependencies:
- python = 3.7.5
- numpy
- pillow
- matplotlib
- pytorch
- torchvision
# - json
# - zipfile
# - csv
- pandas
# - pickle
# - glob
- scikit-learn
- pip # needed to install pip dependencies below
- pip:
# - opencv-contrib-python
- opencv-python
- pyarrow
# - qt
I have been trying to add and remove the qt package.
If I remove qt, I got [qt.qpa.plugin] Could not find the Qt platform plugin "cocoa" in ""
Then I tried to add qt, hoping I can get the cocoa plugin
When I run application, I get
objc[4831]: Class RunLoopModeTracker is implemented in both /opt/miniconda3/envs/grapheme/lib/python3.7/site-packages/cv2/.dylibs/QtCore (0x11e1e87f0) and /opt/miniconda3/envs/grapheme/lib/libQt5Core.5.9.7.dylib (0x1a33234a80). One of the two will be used. Which one is undefined.
loaded library "/opt/miniconda3/envs/grapheme/plugins/platforms/libqcocoa.dylib"
QObject::moveToThread: Current thread (0x7fb18afea390) is not the object's thread (0x7fb18f900090).
Cannot move to target thread (0x7fb18afea390)
You might be loading two sets of Qt binaries into the same process. Check that all plugins are compiled against the right Qt binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of binaries are being loaded.
QObject::moveToThread: Current thread (0x7fb18afea390) is not the object's thread (0x7fb18f900090).
Cannot move to target thread (0x7fb18afea390)
You might be loading two sets of Qt binaries into the same process. Check that all plugins are compiled against the right Qt binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of binaries are being loaded.
qt.qpa.plugin: Could not load the Qt platform plugin "cocoa" in "/opt/miniconda3/envs/grapheme/plugins/platforms/" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: cocoa (from /opt/miniconda3/envs/grapheme/plugins/platforms/), minimal (from /opt/miniconda3/envs/grapheme/plugins/platforms/), offscreen (from /opt/miniconda3/envs/grapheme/plugins/platforms/), cocoa, minimal, offscreen.
This fixed my problem. You can try it.
pip install opencv-python-headless
These packages do not contain any GUI functionality. They are smaller and suitable for more restricted environments.
run pip install opencv-python-headless if you need only main modules
source: https://pypi.org/project/opencv-python/
Related
I am building the Visual Studio Code from the source checked out from the git repository:
git clone https://github.com/microsoft/vscode
I am building using:
export NODE_OPTIONS=--max_old_space_size=2048
./scripts/npm.sh install --arch=armhf
./scripts/code.sh
I am using node 10.16.3 on a Raspberry PI 4, using Raspbian buster
There were no errors during build.
The installation downloads a precompiled version of electron on the first run.
However each time I try and run code, it starts but with an error:
[storage state.vscdb] open(): Unable to open DB due to Error: Cannot find module '../build/Release/sqlite
If I look in node_modules/vscode-sqlite3/build/Release/
I can see:
sqlite3.a
sqlite.a
It is unclear to me why electron/vscode cannot find this library. I would be greatful for any pointers on how to tell the runtime where to look for the modules.
On inspecting the build scripts and after many painful experiments, I've found and solved the 2 problems leading to this error.
The fact that .a static libraries are left behind hinted that some settings in the binding.gyp, config.gpy and/or makefiles are wrong, as Native Node Modules are normally dynamic libraries with an .node extension. One conditional line in the binding.gyp file under vscode-sqlite3 seems to the the culprit:
...
["target_arch=='arm'", {"type": "static_library"}]
...
Disable that line (by removing it or changing 'arm' to something else) and then run:
node-gyp configure
to regenerate the config.gpy file(s) under the build directory. Then build the module with:
node-gyp build
A sqlite.node will be generated in build/Release.
Unfortunately, the latest electron ABI version rarely matches that of the Node.js version. In my configuration, the electron ABI version is 72 (v6.0.12) but the latest stable Node version is for ABI 64. Therefore we have to do an electron-rebuild to update the sqlite.node to match the electron version.
To do this, you would have to first install electron-rebuild (yarn add electron-rebuild) then run electron-rebuild by giving supplying explicitly the version number of the electron binary that vscode downloaded:
electron-rebuild -v 6.0.12 -m /home/dev/vscode -o vscode-sqlite3
Of course you would have to state the version number of your particular version of electron you are building for.
(Please look up electron-rebuild --help for the meaning of the options. It takes a while to rebuild the binary module...)
The resulting sqlite.node can then be moved into the build/Release/. directory under the vscode project directory. Voila, we have a working latest version VS-Code for Raspbian!
I am trying to run the example that can be found here using gstreamer 1.6.4 on my ARM based board (https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/qt/qml)
I have Qt 5.5.1 installed and I have built gstreamer 1.6.4 and all the relevant plugins but when I run the example, it cannot find the GLVideoItem component and comes back with:
qrc:/main.qml:7 module "org.freedesktop.gstreamer.GLVideoItem" is not installed
Now, my question is how can I check if this component is installed on my system?
Also, do I need to rebuild qt linking against the new installation of gstreamer to be able to use this component?
[EDIT]
I also noticed creating qmlglsink element as get_element_factory_make("qmlglsink", NULL) returns NULL.
From shell:
gst-inspect-1.0 qmlglsink
I would check the ldd on your app of which GStreamer is used (if you have some system GStreamer and compiled one).. then you will have to set proper paths to pick the proper one.
ldd ./your-app | grep -i gst
Notice the PKGCONFIG in your .pro file (in the tutorial you linked) - you may check what is pkg config thinking about that:
pkg-config --cflags --libs gstreamer-1.0 gstreamer-video-1.0
Usually my QML files start with import QtQuick 2.4 and other imports. How can I know which is the latest version of the imported modules without having to guess by type and build?
You basically don't have to know. By importing a particular version, you merely declare that you don't need the additional functionality of any potentially newer version. That doesn't mean that you won't use a newer version if one is available - it simply means that your code will refuse to run if only an older version than the one you need is present.
So, you should only change the imported module version if you happen to use the functionality (members, classes, etc.) from a newer version. That's all. And you will know exactly what version you need, since you're using the functionality you read about in the documentation. The documentation will state what module version it applies to.
The documentation for a given Qt Quick module from the Qt that you're using will state this - no need for release notes.
The QML module version information can be found in a file called plugins.qmltypes.
These files use JSON to store information (as far as I am aware).
In these files Qt uses the "exports" specifier to export the name and version of a module.
Example:
exports: ["QtQuick/Accessible 2.0"]
The example shows the version of the QtQuick.Accessible module.
The plugins.qmltypes are stored in a directory of the same name as base level module.
In the case of the example this would be QtQuick.
Base level modules are grouped under a directory titled qml.
That is "usually" located in a directory called qtx (in some case Qt).
Where x is the installed major version of Qt (in my case it would be qt5).
That means the plugins.qmltypes has a path that looks something like this:
/qt5/qml/QtQuick/plugins.qmltypes
The reason im explaining this bottoms up cause the rest of the path is dependent on how you installed Qt:
Package manager (portage) amd64 install path:
/usr/lib64/qt5/qml/
pip PySide6 install path:
~/.local/lib/python3.9/site-packages/PySide6/Qt/qml/
pip PyQt6 install path:
~/.local/lib/python3.9/site-packages/PyQt6/Qt6/qml
~/.local/lib/python3.9/site-packages/PyQt6/Qt6/qml
Package manager (apt) aarch64 install path:
/usr/lib64/aarch64-{forgot this part}-/qt5/qml/
I figure the version out in bulk with:
grep -r "exports:.*\\]" <insert install/OS dependent path>/qml/* | less
This doesnt grab multiple exports that are spread over multiple lines thought.
Since QML comes in 2 major versions when in doubt you could import version 1.0 or 2.0.
I have made an application using QtWebKit, Qt4. I have the binary generated in Fedora 16. Now, I want to run that application on another PC (running some other Fedora version), where Qt is not installed. How can I package my Qt application so that it can run on a platform where Qt is not installed? Is there any command line utility as well as QtCreator utility to do so. I have tried "deploy all" command, but it didn't have any affect.
Create an Installer with the Qt Installer Framework and just supply all needed shared libraries (Win/OSX) or compile statically. Under Linux there is always the problem between system-wide libraries or bundled libraries. The documentation https://qt-project.org/doc/qt-5.0/qtdoc/deployment.html should give you a good start
Obviously, you need to have access to the qt libraries, which are exactly the same version that you used to compile your application.
There are two options :
link qt libraries statically
create a RPM package (see this how)
Also check Deploying Qt Applications.
Since you're deploying using rpm, to systems where Qt 4 rpms are available, you don't need to do anything besides simply adding a dependency on the qt to your rpm's specfile. The user installing your package using yum localinstall will get the Qt dependencies automatically installed. That's the correct way of doing it - it will keep your package size small.
Of course you need a separate rpm build for every fedora/centos major version out there, but that's almost always a requirement.
If your package needs newer Qt version than the one provided by the platform packages, you can still make a specific version dependency (say qt >= 4.7.0) and have a readme that indicates that newer packages can be obtained from a 3rd party repository (epel etc.)
For deployment under Linux I've used Bitrock Installer Tool.
The main thing before deploying is to check your dependencies. You can do that by using command:
ldd appName | grep libQt
After that you'll see list of dependencies. You'll have to set environment variable LD_LIBRARY_PATH to let linker know where're your libraries. To do that:
export LD_LIBRARY_PATH=.
. means current directory
And after that:
./appName $*
After that you'll be able to use your executable with Bitrock Installer Tool.
The error
When I run pip install PySide – whether in a virtual environment or not – build fails with the following error:
... [lots of build info, including a few warnings but no errors, for shiboken]
Linking CXX executable shiboken
ld: framework not found QtCore
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Seeing as I have QtCore installed and the framework present (see below), I'm not sure why that should be.
Setup info
Software versions
OS X 10.8.2
Qt 4.8.4 from the developer distributed binaries
Python 3.3 installed and working normally
XCode 4.6
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.2.1
Virtual environment generating using pyvenv (with and without --no-site-packages)
Other configurations attempted
Python 2.7 installed and working normally
Virtual environment generated using mkvirtualenv (with and without --no-site-packages)
virtualenv 1.8.4
mkvirtualenv 3.6
System configuration
I've confirmed that QtCore is in fact installed correctly: ls /Library/Frameworks shows a number of Frameworks, including QtCore.Framework.
My path currently includes both /Library/Frameworks/QtCore.framework and /Library/Frameworks/QtCore.Framework/Versions/4 – the former of which has a symbolic link to the component in the latter location. I've even tried it with /Library/Frameworks, though for obvious reasons I didn't expect that to help and it did not.
Other notes
I've tried the same thing with easy_install and by doing a pull from the Git repository and building manually using setup.py. As one would expect, they all return the same results.
Things I've already read
PyPi Installation walkthrough
Link error: QtCore.framework/Versions/4/QtCore for architecture x86_64 (Stack Overflow) – but it seems the linker is already asking for the framework, based on the error message I'm receiving.
Mac OS X: trying to link (ld) against a framework (Stack Overflow) – general info on linking against Frameworks; again, I seem to have this covered.
OSX deployment target confusion for 2.8.10 (CMake Mailing list) – looks like a very similar error, but I don't have direct control of the -isysroot flag using pip (or easy_install or even python setup.py) for one and for another, installation structure seems to have changed substantially between OS X 10.6 and 10.8. For example, /Developer no longer has the SDKs directory in it at all.
CMake bug report 0013765 – this one looks exactly the same, but appears to have been patched, so I'm not sure why it would still be causing me a problem.
Preferences
I'm not using a package manager like Homebrew or MacPorts at this time, and I'd prefer not to, either, as I need to get as close as possible to a platform-agnostic installation procedure for this (we're looking at doing cross-platform development; I'll ultimately be targeting Windows applications primarily, but need to see if it's workable on my Mac development machine outside a VM).
It needs to be able to work with a Python 3-style virtual environment (pyvenv) setup, as that's our preferred means of isolating our particular requirements.