I had previously installed PyQt4 on my Windows XP machine and was successful in getting everything to run. This evening, I downloaded the full Qt4 SDK (open source version) and installed it as well. After adding the path to the bin directory to my system environment path I was able to build a few small programs I'd written in C++. Without changing my environment, I started up python and tried to import PyQt4.QtCore and got an error that it couldn't load the DLL. I removed from my environment path, the path to the Qt4 SDK bin directory and was now able to run my python PyQt4 programs but I could no longer build my C++ programs.
First off, I'm not sure why the presence of the C++ SDK should impact the python version because they're in different directories. I assume the issue is that, when python attempts to load the PyQt4 DLL, it thinks its using an executable from the python path but, because the SDK path is first, that (incompatible) version is what is actually invoked.
Is there a way that these two environments can leave peacefully with each other such that I can build and run either type of program?
The issue, as you correctly suggest, tends to be that the versions of the various DLLs (QtCore4.dll, QtGui4.dll etc) are different. I've tended to find that the problem occurs for the one expecting a newer version (so if the Qt SDK is installed second, but PyQt4 is in the path first, the Qt SDK would complain), but it sounds like you've got a different problem.
There are two solutions that I've found to this:
Change your path for the different build/run environments (not very nice).
Make sure both PyQt4 and Qt/C++ are at the same Qt version so that either DLL will work (generally much easier).
Since I have started installing both PyQt4 and Qt/C++ on a computer when I first start using it (and therefore they are at equivalent release versions), I have rarely had any problems with them coexisting.
Related
I noticed that deployed on windows Qt applications are always including the dlls they needed.
Why did they made it that way?
Why can't they do it like on linux? - You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5).
Wouldn't it be better to make it like Java/.Net, e.g. you install Java/.Net then you run/develop applications using only one instance of libraries(dlls).
I find it kinda "unconservating": I have 7 applications that use Qt5, and all of them have Qt5Core.dll, Qt5GUI.dll, etc. and every of them takes some space. Feels like I have 7 packs of Qt5 libraries... x_x
While on linux these same applications use only "one" Qt library.
I noticed that deployed on windows Qt applications are always including the dlls they needed.
This is called "local deployment".
Why did they made it that way?
I can think of a few reasons.
To avoid DLL Hell.
It is sanctioned by Microsoft. They wrote, "You can use this deployment method to enable installation by users who don't have administrator rights, or for applications that can be run from a network share." (see https://learn.microsoft.com/en-us/cpp/windows/choosing-a-deployment-method?view=vs-2019)
You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5)
Qt is a C++ library. C++ DLLs can differ by more than just a major version number. The DLLs could be built with MinGW, or they could be built with MSVC; They could be 32-bit, or they could be 64-bit. The different variants are incompatible with each other.
Example: if you force a PC to have one global copy of Qt 5.14.1 MSVC 32-bit and put that in your PATH, then:
Other Qt apps on that PC that are built with MinGW cannot run.
Other Qt apps on that PC that are 64-bit cannot run.
Apps that must use Qt 5.13 might be broken. (For example, if a critical bug exists in Qt 5.14)
Why can't they do it like on linux? .... on linux these same applications use only "one" Qt library.
I listed a few disadvantages of this approach above. In addition, the version of Qt in Linux distros are usually a few versions behind so applications in the distro repository cannot make use the latest features, bugfixes, or improvements.
That's part of the reason why systems like AppImage and Snapcraft were invented. Sometimes, Linux users also want an app to contain a copy of its libraries, instead of having a single global copy of the libraries.
I could find that vs2015 comes with mussel library which is more like to use POSIX calls. I went through the installation guide provided and through the official link, came to know that I need to run configuration file followed by make.
But the configuration file has not been provided with vs2015.
I request you to let me know the procedure if someone has done this before.
musl doesn't support Windows; from the FAQ page:
What are musl’s dependencies?
Linux 2.6 or later. Earlier versions will suffice for running most simple single-threaded programs, but due to bugs and conformance issues at the kernel level, musl is not offically supported on earlier kernels.
(now, Windows 10 does support running Linux binaries through WSL, but in that case you would be building musl through gcc inside the Linux "container" and it would be another kind of game entirely)
As it comes as VS2015 along with third party license I thought there should be a way to get it done. The folder location is Microsoft Visual Studio 14.0\VC\vcpackages\IntelliSense\iOS\OSS\musl-1.1.10
As said in the comment, from the folder name it seems that it's there just to aid IntelliSense when editing code for iOS targets.
I'm building and OS X app that needs a set of dynamic libraries in order to run (Graphviz Libraries). On the machine I'm developing on it works fine but when I tried running the app on another machine the app crashes (which does not surprise me) probably because it doesn't find the libraries, they are installed but in a different location.
My question is what is the best way to make sure your program works?
Graphviz libraries should be installed into "/usr/local", but can be installed in other places.
There are ways to include dylibs in application packages you build (this related question's answer has more info), but it's a bit of a hassle to set up the build steps / phases in Xcode to do the extra steps at build time (such as calling "install_name_tool" to point to "#executable_path").
If your app is going to be installed on not too many machines, I'd recommend just making certain that Graphviz is properly installed into the expected place. If you're going to distribute this app far & wide, you might as well include the Graphviz dylibs within your app package. A third -- possible -- option might be to call the Graphviz installer as a sub-installer from an installer that you create.
Is it possible to develop cross-platform application on Windows and can also compile for Mac OS X from Windows? I have checked Qt but that requires one to compile from Mac using Xcode.
If this is your priority then one option would be Java as at least a jar file built on one platform can be run on another.
If however you're talking about C or C++...
If you are creating a small command line tool then you might be able to make this work with gcc and a cross compiler, but I think it would be a lot of work.
If however you are wanting to create a GUI application I would urge you to give up now. There are so many issues - you'd have to use Carbon or Cocoa APIs which you can't build for on any other platform, you'd have to link against frameworks which won't exist on your compilation host, you won't be able to easily generate .plist files. Qt won't help as you need to be able to build it, which relies on these same frameworks.
In short, there's no alternative to building on an actual mac.
Furthermore, when it comes to fixing bugs, you will absolutely have to do this on a mac (either physical or virtual).
From what I know , in general you do need a mac to make the executable , even for a simple ansi c program you need gcc for mac.
You can create MacPorts Portfile.(If your application is open source)
A MacPorts port is a set of specifications contained in a Portfile
that defines an application, its characteristics, and any files or
special instructions required to install it. This allows you to use a
single command to tell MacPorts to automatically download, compile,
and install applications and libraries.
Take a look at IMCROSS.
IMCROSS is a simple, scripted method of installing cross-compilers and
cross-compiled libraries on a Linux (or possibly other *nix) system,
so that you can develop programs targeted to run on Microsoft Windows
and Mac OS X at the same time and in the same environment as you
develop Linux versions of those programs.
You can certainly do this using Real Studio. It can create Mac OS X applications on Windows without any trouble.
It cross-compiles for Windows, OS X and Linux. And it does it from any platform. It also can create web apps.
Sounds like you should check it out.
I have a mac application that uses twain (Relies on 3 packages that I had to install: libusb, sane backends, and twain sane interface) and imagemagick which I also used a package to install and I'm not really sure how to go about redistributing them.
I'm thinking I would have to include the source for each package I rely on, libusb-1.0.9.tar.bz2 for example for the lib usb package, and then configure and make each of those in /use/local/bin (Basing that off seeing it done by the binary packages). I imagine I would have to add these locations to $PATH once done.
I was trying this myself but ran into this error: "configure: error: no acceptable C compiler found in $PATH" so am now downloading xcode developer tools. I imagine the end user for my installer will run into this issue as well though if they don't have it installed so I'm now not sure how to proceed.
Can anyone shed some light on how to properly distribute tools that your app relies on? I am using FileStorm Pro and was planning on using applescript shell commands to do the command line work.
Unless you were planning to distribute your application as source, you definitely don't want to distribute its dependencies as source. Most Mac users do not have the Xcode developer tools, and do not want them.
Build the binaries on your machine (ideally on a clean machine with the oldest version of OS X you want to support, the newest version of Xcode that works on that OS, and nothing else installed on it). Then copy the resulting binaries somewhere into your .app bundle. Then, instead of running the tools in a way that relies on $PATH, launch them by an explicit path relative to argv[0] or [NSBundle mainBundle].
(And make sure to check the licenses of every third-party tool you're using.)