I am using Qt 4.8.1, MinGW compiler and Qt Creator, all on windows 7. I want to add an encryption/ decryption library to my project. After searching the web for couple days I found QCA. Fortunately I found a pre-built version using the same C++ compiler I am using, and a pre-built version of the needed plugins.
I followed the instructions to add the QCA library to my project. I used a code like this to encrypt using AES:
QCA::Initializer init = QCA::Initializer();
//Here where the execution stops
QCA::SymmetricKey key = QCA::SymmetricKey(16);
QCA::InitializationVector iv = QCA::InitializationVector(16);
QCA::Cipher cipher = QCA::Cipher(QString("aes128"), QCA::Cipher::CBC,
QCA::Cipher::DefaultPadding, QCA::Encode,
key, iv);
if (!QCA::isSupported("aes128-cbc-pkcs7"))
{
qDebug() << "AES128 is not supported";
return;
}
The code compiles just fine but when I run the application stops with unknown reason.
I really got tired from this bug, if anybody can help it will be very very very appreciated.
For future programmers that might get stuck on this
QCA loads the plugins at runtime, so even if it compiles fine, if the plugin is not in a searchable folder, it won't load.
You can check if that's the problem by calling qDebug() << QCA::supportedFeatures();. If the plugins are not being loaded, you'll get something like:
("random", "md5", "sha1", "keystorelist")
You should be able to see the folders QCA is looking up by calling:
qDebug("%s", QCA::pluginDiagnosticText().toUtf8().constData());
Apparently, plugins must be placed in a subdirectory called crypto in the libs root directory.
You can check for all the paths where Qt looks for libraries using:
qDebug() << QCoreApplication::instance()->libraryPaths();
This documentation might have some useful information: http://doc.qt.io/qt-4.8/qpluginloader.html
Related
I am developing a QT GUI for my application using QT Creator (4.11.0).
Recently, our IT updated my OS to Ubuntu 20.04 (from 18.04) - maybe the error is related to that.
I have not touched to project in some month but yesterday wanted to continue developing it.
However, within the IDE there are now thousands of errors highlighted at almost every line of my code. (with highlighted I mean that there is this red background and a red dot beside the line number)
On the very top, it says:
Warning: The code model could not parse an included file, which might lead to incorrect code completion and highlighting, for example.
cstddef:50:10: fatal error: 'stddef.h' file not found
...
The errors that are listed in the IDE are very wired like:
type `QMainWindow`is not a direct or virtual base of `MainWindow` (my class is called `MainWindow`)
I'm pretty sure it is not related to my code:
the code compiles and works fine - it is really just the IDE that is highlighting errors at every line of my code.
I have the same code on a Windows Computer and there no errors are listed in the IDE.
even if I start a brand new QT Widget project the errors appear within the template code provided by the QT Creator.
Since the GCC version changed with the update of the OS, I thought maybe I have to define a new KIT but this also did not help.
Is there anything I can do to fix the issue?
Do I have to reinstall the QT Creator?
I know, pictures are not very well-liked but here I think it might help to understand what I mean with "IDE is highlighting errors":
1. First
~/.profile :
CPATH="/usr/include/clang/10/include:$CPATH"
C_INCLUDE_PATH="/usr/include/clang/10/include:$C_INCLUDE_PATH"
CPLUS_INCLUDE_PATH="/usr/include/clang/10/include:$CPLUS_INCLUDE_PATH"
export CPATH
export C_INCLUDE_PATH
export CPLUS_INCLUDE_PATH
maybe /usr/include/clang/10/include see in you file system.
2. Second
Logout / login.
3. Third
Specifying Build Settings (Projects -> Build -> in every config build) in Build Environment section: [unset] CPATH, C_INCLUDE_PATH and CPLUS_INCLUDE_PATH
or [edit] replace this variable with the necessary values
I fixed this issue by sudo apt install clang-8.
Source: https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1890434
I'm facing the following problem:
I wrote a simple application to track working hours. Therefor I create a *.db file programmatically.
Launching the application from Qt Creator (debug or release) works perfectly fine.
I used the macdeployqt tool to get a *.dmg file. When starting the application now the method (see below) cannot open, respectively create the *.db file and I run out of ideas why. In addition to this, the application should output some *.csv files. This also fails.
One more information, running the application as administrator using the sudo command on terminal...well it works and the *.db file and *.csv files get created.
So I am quite sure it must deal with file permissions but I have no idea how to change this except for changing it in the information context menu but this didn't help at all.
Below the method for the *.db file which always returns false when not launching the app from Qt Creator:
QFile file(Globals::Environment::WORKING_DIRECTORY + "/" + "Records.db");
if(file.open(QIODevice::ReadWrite))
return true;
else
{
QMessageBox msg;
msg.setWindowTitle("Error");
msg.setText("Failed to create database file!");
msg.exec();
}
return false;
I am on MacOS 10.11.3.
Qt 5.5.1 (Clang 6.1 (Apple), 64 bit)
If more information is needed, I will provide it of course.
Thanks a lot for every help in advance.
I compiled bitoin-qt,PTS coin and other Altercoins successfully ,but thay all can't running.
I use MinGW4.4 ,QT 4.8.5 download from website and QT creator 2.8.1.
This is my .pro setting:
BOOST_LIB_SUFFIX=-mgw44-mt-s-1_53
BOOST_INCLUDE_PATH=D:/C/coin/namecoinq/libs/boost_1_53_0
BOOST_LIB_PATH=D:/C/coin/namecoinq/libs/boost_1_53_0/stage/lib
BDB_INCLUDE_PATH=D:/C/coin/namecoinq/libs/db-4.8.30.NC/build_unix
BDB_LIB_PATH=D:/C/coin/namecoinq/libs/db-4.8.30.NC/build_unix
OPENSSL_INCLUDE_PATH=D:/C/coin/namecoinq/libs/openssl-1.0.1e/include
OPENSSL_LIB_PATH=D:/C/coin/namecoinq/libs/openssl-1.0.1e
MINIUPNPC_INCLUDE_PATH=D:/C/coin/namecoinq/libs
MINIUPNPC_LIB_PATH=D:/C/coin/namecoinq/libs/miniupnpc-1.8
And I uncommented this code because MinGW4.4 doesn't suport it(I've used MinGW 4.6,4.7,4.8,but they all even compiled failed) :
#win32:QMAKE_LFLAGS *= -Wl,--dynamicbase -Wl,--nxcompat
These all compiled by MinGW4.4 succefully,but the debug and release exe compiled both can't run.I have coped the qt dlls to the exe direction.When I debugged it,it broke before entering the main source.
======================UPDATE edit==========================
I know it's because of leveldb,but I don't know what's wrong with my compiling leveldb:
TARGET_OS=NATIVE_WINDOWS mingw32-make libleveldb.a libmemenv.a
When I use another altercoin leveldb source code,the error solves.But I use back to the original leveldb source code,the program breaks again.
Still seems to me you are missing a .dll. Try using dependency walker and verify you are not missing any dependencies.
I have a strange issue that appeared only recently.
When I acces an external binary from inside my Qt app, the app crashes with the error:
Exception Type: EXC_CRASH (SIGABRT)
But when I run it from the "build and run" inside Qt Creator, everything runs fine when I acces the point in my application where I hit an exetrnal binary.
This is the function I hit when the app crashes from outside Qt creator
QString Api::getVideoFrame(QString filename, QString position)
{
const QString ffmpeg = QDir::currentPath()+"/ffmpeg"; //mac version
QProcess process;
QStringList args;
args << "-ss" << position
<< "-i" << filename
<< "-f" << "image2"
<< "-vframes" << "1"
//<< "-vcodec" << "bmp"
<< "pipe:1";
process.start(ffmpeg, args);
process.waitForFinished();
return QString(process.readAllStandardOutput().toBase64());
}
It also crashes when accessing other external binaries, not only ffmpeg in this case.
I have the feeling it has something to do with the QDir::currentPath() because when I mess up the path, It also crashes from inside Qt Creator.
obviously I added the corresponding binaries next to the executable file in the Contents/MacOS/ folder
I don't really know how to debug this.. any clue how to solve this?
I actually found out why this happens and it is quite interresting to note that
QDir::currentPath()
has to be used with care on mac osX.
When an app is executed from within Qt Creator it returns :
/Volumes/LSPRO/Build/LSPRO.app/Contents/MacOS
including the path to te binary inside the .app package
But when you run it as a standalone app, it returns
/Volumes/LSPRO/Build
At least on my configuration...
I don't really know how to debug this.. any clue how to solve this?
Yes, I have some clue.
You could try using QCoreApplication::applicationDirPath() for this scenario to get this working properly on MAC as also asserted by a user in the comment.
Here you can find the filesystem engine source code though if you wanna further track the issue down with your suspect as a bug. In short, there is not much Mac specific code in there rather than Unix.
Also, in the future you may wanna consider QtMultimedia rather than dealing with QProcess and external execution.
I am busy converting by existing firebreath plugin here to use gpgme instead of making calls via the OS and the gpg binary.
I have managed to get the code to compile in windows using VS 2010 on a x32 system but after loading the plugin into chrome I can not access the npapi code at all. Even simple version calls fails.
When loading the plugin I get no visible errors but when using sawbuck log viewer for chrome I get the erorr messages below.
.\renderer\webplugin_delegate_proxy.cc 347 PluginMsg_Init returned false
..\plugins\npapi\webplugin_impl.cc 271 Couldn't initialize plug-in
I have tried to use my code with both firebreath 1.4 and 1.6 and neither versions work. After some simple debugging it seems that using any code provided by gpgme (whether its called or not) causes the plugin to break.
I came to this conclusion by doing the following.
Created a new project with firebreath (versions 1.4 and 1.6)
Add the gpgme.h headers to gmailGPGAPI.cpp and changed nothing else aside from adding the required reference paths to the project.
Build the project to create the dll (this generates the dll fine).
Replace the existing ddl in my project with the dll in step 2 and test it with the following piece of code
plugin = document.createElement('object'); plugin.id = 'plugin';
plugin.type = 'application/x-gmailtest';
document.body.appendChild(plugin);
console.log("my plugin returned: "+ plugin.valid);
console.log("my plugin returned: " + plugin.version);
This returns valid = true and the version returns what ever i set it to.
I then modified gmailGPGAPI.cpp to now return the gpg version by calling gpgme_check_version(NULL) in the version method. I used that method because its probably the simplest returning function that I could test with.
Build the plugin and copy dll to chrome extension as in step 3-4. The plugin builds fine again as expected.
Load the plugin and try to execute the code in step 4 at which point it now just returns undefined for any property or method i try to access on the plugin. No errors are printed to the console or anywhere else in chrome except for the error logged to sawbuck.
I have got no idea where to look or what to try since I cant seem to get an actionable error to work against. I have also reduced by test code to the point where its just a new project with a one line change to make it easier to find the problem.
I should note the code in the repo builds fine in linux/OSX and loads into chrome correctly so I know at some level my code does work.
Two possible paths:
You may have a DLL dependency that isn't available which keeps the plugin from loading; if you run regsvr32 on it in the state where it doesn't work on chrome, does it work?
Your plugin may be loading and then crashing. Start chrome with --plugin-startup-dialog and then when it pops up a dialog warning you that a plugin is about to be loaded attach to that process and see if the process crashes. At this point you can also set breakpoints to try to figure out how far it gets.
Double check your metadata in PluginConfig.cmake as well; sometimes unusual characters in some fields can cause issues like this.