I have a existing 64-bit Qt Linux project (C/C++), now I wanted to add additional hardware. Unfortunately the hardware vendor provides a SDK with 32-bit binary-only C .so.
Just including the library leads to an error like this:
/usr/bin/x86_64-linux-gnu-ld: skipping incompatible /home/SDK/lib when searching for -example
/usr/bin/x86_64-linux-gnu-ld: cannot find -example
Is there any way to include this library into my existing project?
I found Mixing 32 and 64-bit Libraries in Linux (gcc), but maybe there are some changes as it's already 7 years old.
Thank you in advance!
The x86 and amd64 ABIs are completely different on Linux, so you can't call 32-bit libraries from 64-bit code directly. That said, you can achieve your objective by creating a separate 32-bit program that proxies calls into the library and exposes them via REST, WSDL, Protobuf, or your favorite way of doing IPCs, and then making those calls from the 64-bit process.
Related
I am setting up a Qt project which will be cross-copiled for a given display (running on ARM/Linux). The display will come with a self-contained cross-build toolchain which comprises Qt libraries with a specific Qt version (probably 5.15).
Now I would like to use a specific "static" toolchain incl. Qt libraries to also generate x86-builds of this Qt project (for testing, simulation; building/running on Linux and maybe also on Windows).
I'd avoid using the GCC and Qt development files introduced by the Linux package manager (e.g. apt), because the are not tied to a specific Qt version, i.e. upgrading the OS would always come with the risk to introduce build problems or break compatibility completely.
Are there good-practice approaches to achieve this?
So far I see three options:
Use a docker image
Possible problems:
Finding a image with the correct Qt version
building the Qt application would then work, but to execute it, the compatible Qt LGPL shared libs need to be available to the Qt application binary
Use a x86 -> x86 "standalone" toolchain
Find some standalone x86-toolchain analog to those (x86 -> x86), but additionaly...
it would either have to come with the Qt development files in the correct version
or we would have to build the Qt sources with this toolchain, and then extend the toolchain with the Qt built artifacts
Would be the preferred solution (and currently seems to be the most feasible of the approaches I can think of).
Virtual machine
Possible problems:
Finding a OS version with the correct Qt version
Select a OS version that contains the correct Qt version via package manager.
Not very elegant.
Qt online installer
only provides a limited choice of Qt versions (as of today: 5.15.2, 6.2.4, 6.3.2, 6.4.0) which is probably subject to change in the future
I got an app, that is ready to release. On windows, I simply type 'windeployqt.exe MyApp.exe' inside 'release' folder of app build in special qt cmd. I'm trying to do the same on kali linux (I dont have time to install other deb based distro). I'm searching for solution for three hours, and I cant find anything good. So, how to make application executable on other linux computer without Qt Creator installed?
There are many ways to deploy Qt applications on Linux. AppImage created with the help of linuxdeployqt or linuxdeploy-plugin-qt is one option, perhaps even the simplest one but it has its drawbacks. From my personal experience I can think of two:
Your app won't generally be able to use native icon/font/other themes.
Sometimes your AppImages might occasionally cease to work due to some unexpected system update which would, for example, break the binary compatibility of OpenSSL libraries.
Other packaging options for Linux include:
Linking the application with static version of Qt. It is the
approach used e.g. by Telegram. The instructions can be found
here.
Beware, however, that using this approach for commercial closed
source applications generally requires commercial Qt license.
Probably it is possible to get away with LGPL but it would be very
cumbersome: you'd have to provide customers with compiled object
files so that they can replace them and re-link the app. Also beware
of the fact that if the application you intend to create is going to
be an open source one, the maintainers of Linux distributions would
generally not agree to distribute statically linked applications -
that violates the basic rules for many distros according to which
applications should not bundle their dependencies but instead should
use the system provided libraries. It is important from e.g.
security perspective - if some security threat is found in Qt in
future, it can be fixed within a Qt library itself and all
applications using that library would then also be secure -
something not that easily achievable with application built with
static version of Qt.
Creating native packages for target systems - i.e. deb packages for
Debian/Ubuntu systems and their derivatives, rpms for Fedora,
OpenSUSE and other rpm-based distros,
PKGBUILD for Arch
Linux and various other kinds of packages for various other distros,
hundreds of them. The advantage is good integration with the rest of the system: native themes etc. Also you get all the advantages of the security fixes for shared libraries.
Using flatpak or snap packages - these are modern app packaging formats developed by RedHat and Canonical respectively with the goal to simplify the management of app's dependencies.
Using the generic approach using shared libraries - with this approach you'd need to package your app as an archive containing a directory containing you app and all its dependencies in the form of shared libraries - something similar to the approach of deployment on Windows where you put the dlls alongside the app.
I would recommend trying an AppImage first and then creating native packages for target distros.
I'm trying to build a simple application with CUDA and I've been trying for hours on end and I just can't make it work on windows. nvcc absolutely refuses to compile without Visual Studio's compiler which doesn't support things I need. I tried building using nvcc with clang but It just asks me to use Visual Studio's compiler. I've also tried using clang directly since it now supports CUDA but I receive this error:
clang++.exe: error: Unsupported CUDA gpu architecture: compute_52
This makes no sense to me because I have the CUDA toolkit version 7.5 and my graphics card is a GTX 970 (two of them). I have googled this extensively and everywhere I come across the error the person always has is their CUDA toolkit is < 7.5. I'm on the brink of tears right now trying to get something as simple as VLA to work on this CUDA application and I just can't achieve it...
The CUDA windows toolchain requires the Visual Studio C++ compiler. You cannot use anything else on that platform. If the VS compiler doesn't support the language features you need within CUDA host code, you have no choice but to change platforms, or your expectations.
You can still potentially compile non-CUDA host code using another compiler and then link that code using NVCC and the VS toolchain.
Try to use clang-cl, --cubin=clang-cl.exe
It may be worth to work on a Linux VM or WSL2 within windows. As per the CUDA docs.
To compile new CUDA applications, a CUDA Toolkit for Linux x86 is
needed. CUDA Toolkit support for WSL is still in preview stage as
developer tools such as profilers are not available yet. However, CUDA
application development is fully supported in the WSL2 environment, as
a result, users should be able to compile new CUDA Linux applications
with the latest CUDA Toolkit for x86 Linux.
https://docs.nvidia.com/cuda/wsl-user-guide/index.html#:~:text=However%2C%20CUDA%20application%20development%20is,becomes%20available%20within%20WSL%202.
I am developing an application in Qt, but using D language (with QtD binding). I've noticed that my app crashes with Qt 4.7.x, so I need to use Qt 4.6.2 instead. However in my system Qt 4.7.2 is installed. Unfortunately I neither make QtD work with the latest Qt versions nor (I'm afraid) count on QtD developers...
The only thing I need to make my application install in system Qt 4.6.2 libs and use it, but let all the other applications still use Qt 4.7.2. Is it possible? If it is, how to do it then?
The answer to your question is the version of Qt is determined by the qmake you use to generate your Makefile.
/opt/QtSDK/Qt-4.6.2/bin/qmake
/opt/QtSDK/Qt-4.7.3/bin/qmake
Each will use the library in the directory.
It is possible to install several versions of the library into one system, and all package managers (rpm, deb) support this out of the box.
These libraries will be just differently named. For example, if id do
ls /usr/lib/ | grep libcurl
on my system, I'll get:
libcurl-gnutls.so.3
libcurl-gnutls.so.4
libcurl-gnutls.so.4.2.0
libcurl.so.3
libcurl.so.4
libcurl.so.4.2.0
, so, different version of the same library happily live together.
All you need to do is to link against the desired version of QT library. You need to sepcify it in linker options (don't remember the exact option).
I have a windows screensaver that I want to recompile using the QT libraries, so that I can make available for more platforms.
I am facing problems with the deployment on Vista and XP.
I compile my screensaver statically with MT, and run the dependency checker.
The results are:
MyScreensaver.SCR needs several DLLS, QTCORE4.DLL but no MSVCx80.DLLs.
So far this is fine.
My problem is that QTCORE4.DLL in its turn, does need MSVCP80.DLL and MSVCR80.DLL
As a result my application does not run on Vista systems.
Can I build QTCORE4.DLL to be statically linked the the microsoft libraries (maybe Libcmt.lib ?) so that I do not have any dependencies in the MS CRT DLLs?
Limitations:
I do not want to have the users install the MS VC redistributables. The screensaver is only 1 MB, and it is ridiculus to ask the user to do so many changes in his computer just for a screensaver.
I do not want to use the trick to put the MS CRT dlls in the same application path with the screensaver because screensavers are installed in system32, and I want to install the minimum possible files there.
Finally, I do prefer to produce a monolithic program, rather that a bunch of DLLs
I tried a full static compilation and link of QT, but this is not allowed (if I understood correctly, by the LGPL) and also it is not recommended according to this: http://www.qtsoftware.com/developer/faqs/why-does-a-statically-built-qt-use-the-dynamic-visual-studio-runtime-libraries-do-i-need-to-deploy-those-with-my-application
After trying for solutions in various directions, it seems the most feasible one is to use the QTCore4.dll and QTGui4.dll, but having them linked statically to MSVCRT. In this way, neither my program, nor the QT DLLs will have dependencies on MSVCRT dlls.
Is there a solution to this?
( I am new to QT programming )
Thank you,
Michael
I think they are concerted that parts of your application will be compiled with /MD(d) and parts with /MT(d), but if you control everything (including 3rd party libraries) then its pretty safe to use /MT(d).
You have two options:
Those dependencies are part of Microsoft Visual C++ Runtime Library, you can deploy that library in your installshield and user silently installs it, MSVCRT library not included in Windows by default, you must deploy runtime library in your installshield and copy Qt*.dll DLLs in your application directory.
Use Static Linking of Runtime and Qt main dependencies, with this option you have one executable file, but to static compile of Qt you must have Qt commercial License for commercial use.