We are wrting a C++ application which links to MySQL shared Library dynamically to communicate with Server. My question is for normal queries and stuff (which is supported by almost every library) , Is it necessary to enforce the Server and Library versions to be same ?
Note: There is mysql-shared-compat RPM which solves this issue but it contains all the libraries from previous releases. And we dont want to ask the user to install that package along with mysql-shared package.
I've found this discusson, HTH: http://lists.mysql.com/mysql/210702
Our client-server protocol has not changed much, if at all, in a long
while. You should be quite safe using a 5.x-based client library to talk
to a 4.1 and even a 3.x server.
Related
I built a qt c++ application on a Linux system which uses network requests as part of its functionality, and on the system which it was built on it works alright, after I deployed it (using cqtdeployer), and ran the application on a different Linux computer, the GUI opens up and everything, but when it tries to perform HTTP requests it logs the following error to the console:
qt.tlsbackend.ossl: Incompatible version of OpenSSL (built with OpenSSL 1.x, runtime version is >= 3.x)
My question is - can Qt be built with modern OpenSSL versions, or do I have to manually install OpenSSL1.x on the computer which tries to run the program? Maybe I can just provide a bunch of libraries to the deployment folder?
Thanks.
OpenSSL is generally binary incompatible between major versions, especially with version 3, which is a major API change.
Perhaps it will be a good investment of time for you to take this opportunity to learn how to use your Linux distribution's package manager, (rpm/dnf on Fedora-based Linux distributions, and dpkg/apt on Debian-derived distributions) which exists precisely to solve these kinds of problems.
Most major Linux distributions still include an additional compatibility package for code that's built with OpenSSL 1. If you use your Linux distribution's package manager and prepared an appropriate package, the compatibility package would've gotten installed, automatically, by the package manager together with your package. That's what the package manager is for.
It's also a fair chance that the version of Qt is different too, and there's also a high chance of an incompatibility between your code that's compiled for one version of Qt and the different version that's installed on the computer in question, even though it seemingly runs. If you used the package manager it would've figured it out too, and alerted you.
I post the following question at LunarG, as Issue #565, about Vulkan SDK redistributable parts for ready to go applications developed with Vulkan. I'd like to share it with Stack Overflow developers.
Let's say I have Vulkan application demo and wish to send it to
potential clients, in order to evaluate it. If I'd develop it using
SDK, what is the correct way to deploy it :
a) include the compatible SDK installer in a multi-install process ?
b) include some SDK's dlls and companion files ? Which ones ?
It also raises another question: Can I re-distribute SDK files ?
Karl Schultz, from LunarG, replied with the following:
On Windows, many IHVs include the Vulkan loader DLL in their install
packages, placing it in system32/vulkan-1.dll. So, in many cases, your
app might just work fine as long as the user has installed drivers
with Vulkan support.
You might also consider shipping only the RunTimeInstaller, which is
found in the SDK. This would let the user install the run time
(loader) as part of your application install. The RTI includes version
checking so that it doesn't clobber a newer version installed by IHV
drivers, or vice-versa. In short, this is probably the best way to go.
It would be better to include the RTI as part of the "multi-install
process" rather than include the entire SDK.
If your application needs layers or some other specific item from the
SDK, then you'd have to include those explicitly somehow.
Please check the licensing-related files within the SDK concerning
redistribution.
i will explain my problem and please try to help me
i want to access a web-service from Point-Of-Cell Handheld
its SDK use C language on eclipse
at first i wanted to learn how to access web-services from C or c++ LANGUAGE
and i succeeded in this using gsoap library and i can access a web-service using it.
i modified the stdsoap2.c file to can fit the handheld library as i modified tcp-connect and tcp-send and tcp-receive and so on
my problem here there is alot of errors in this file, it is run time error as memory fail or pthread fail and so on
my director told me that it is because this file is for windows and ask me to search for gsoap version work on another platform
he tried the Linux version but it didn't work too
he asked me to search for a copy that work on embedded system or on FreeBSD OS
is he right? and is there any copy of gsoap can satisfy my need?
Gsoap is available on FreeBSD. Just install the port from /usr/ports/devel/gsoap
If your code was written for windows, you will have to replace windows-specific functions with those available on FreeBSD.
I'm looking for cross platform open source third party library for web services which support c++. I have generated c++ files using WSMakeStubs utility but it uses Core Foundation data types. I want a library which provide web service call through c++ so that I can use it on Windows and Mac both the platform.
I wanted stubs that can be used on both Windows and Mac platform.
Could any one suggest me good library.
thanks
I would like to recommend gSoap. In the company I'm working at, we use it for about 7 years now (since version 2.6.0, the actual version is 2.8.3) and only made good experiences with it. Look at the success stories to get an overview of the companies which are using it.
Related:
C++ and SOAP
What is a good platform for devoloping web services in C++?
A Good C++ Library for SOAP
pion is a possibility, though I don't know how it compares to gSoap or other alternatives. I got it working an evening then got distracted with other reverse economies. I seem to remember it having fewer dependencies of the others I researched.
Sorry i'm a beginner,from what i know there are number of varieties of libraries and framework out there provided for the C++ language.My question is,when we create an application using the framework and libraries,do the users of the application need to install the framework or so so call the libraries on his/her PC??Thank You
It depends whether the library you are using is statically or dynamically linked. In the former case, it is part of the executable file that you distribute. In the latter case, it is an extra file (or set of files) with extensions such as .so or .dll, which you should distribute with your app.
Yes, libraries must be bundled with your application/installed before hand, as they are the framework upon which your application relies. If you don't install the framework, your application will not work.
You need to install something, not necessarily the framework. Some frameworks, like DirectX for example have a client installation. Some components are simple dll files that you can deliver with your software, creating an installation package.
The end-user need to have the framework installed.
As you need to have .Net installed to run some Microsoft(and other companies) products. If your application is written in C++ using GTK or Qt. You need to have they installed, but if you're on Linux using KDE, Qt is natively installed for default, the same for Gnome and also the same of Cocoa on Mac and Cocoa-Touch on iPhone and iPod Touch.
I suggest you to have the installer of the framework used embedded on the installer of your application. As GIMP and Xchat do.
Generally when using a framework there will be a framework redistributable (.NET, DirectX, etc) which can be bootstrapped into your installation to install the framework (or run by the end user as the first part of "installing" your app).
Many libraries simply need to be included with your code to function correctly, they themselves might have dependencies which need to be installed but these should be called out.
If in doubt, before you distribute your package run it on a fresh install of your target system (Linux, Windows, etc) and see if it complains about missing dependencies. Include those in your package and try again.
You can also look at installation systems (RPM, Apt, Windows Installer, etc) which can handle all of these tasks for you directly (or provide scripting languages to help you automate the job).