Hope to get some pointers here. I am trying to get QT to compile with slightly different code for each platform. For example,
If platform is Windows then include windows.h
If platform is OSX then include time.h
AND
If platform is Windows use QueryPerformanceCounter function from windows.h
If platform is Linux use gettimeofdayfunction from time.h
The objective here is to write wrapper function to return elapsed microseconds that works with Windows (QueryPerformanceCounter) & Linux/Max (gettimeofday) without having 2 sets of code. Qtimer resolution is inadequate in Windows XP. (about 10-15ms increments).
Anyone can point me to a tutorial on how to do this ? Thank you in advance and Happy New Year to everyone here.
Gary Cho
If this was python, I'd say just create a module that conditionally imports one of the correct modules.
This being C++, I'm fairly certain this isn't possible (I'm not a C++ expert). Even if the compiled binaries were able to run on both windows and linux machines. I don't see any way to compile both windows and linux headers into an executable and then choose between them at runtime.
You're going to need to compile 2 binaries that each include the correct header.
Related
Hi I have a debian image on BBB I have already installed QT creator on B^3 but the problem is whenever I try to start a new project in qt creator, couldn't see any option of kit. Infact when i add qmake and compiler path the application throws error.
What can I do to solve the problem. Can i directly get the full pack of SDK from qt.io/download ?
You must compile Qt libraries for your device (BBB) on your own, using specified compiler. You can find more information on this topic, here:
Qt Cross-Compilation Options
As soon as you compile Qt libraries for your device, you must move them to appropriate directories (on your BBB).
First, I would suggest learning to cross-compile, it's much faster & more easily maintained when you want to move to new versions. There's a ton of documentation and community around doing this. Windows & Linux both of which are probably dated, but info is still relavent. I've heard it's much easier from a linux host, but that could be biased.
That being said, if you don't want to cross-compile I believe you can simply install the qt embedded libraries. This question may offer some good advice. Once you have the libraries installed, you should be able to use qmake directly to create the Makefile for your project, then you can use cmake, or g++, etc.. to do the actual compiling.
You're likely going to work in command line though, I'm not sure you can run QT Creator on the BBB directly. I could be wrong.
Please help me find a portable version of Qt 5.1.1 for Windows 32-bit. If there is none available, please tell me how to create one. I've never done it, so I'll need a step-by-step instructions.
Thanks in advance!
Baha
Qt is not portable, they're dumb enough to hardcode the install path not only into config files, but into BINARIES too.
You can create a bin/qt.conf file though, e.g.
[Paths]
Prefix = c:/lib/Qt/4.8.5
Then check the result with bin/qmake.exe -query, it should show the given path in the config file.
Too bad 4.8.5 crashes when qt.conf is present, and there's no 4.8.6 yet...
All Qt versions are supposed to be portable - it is the nature of this framework. You can find desired binary version of Qt here.
Portability is not at binary-level but at source-level. It means that you can port an application written in standard C++ and Qt among different platforms (e.g., Windows, Linux, Mac, and so on).
I am using Qt in order to build a cross platform GUI app (Windows and Mac). I want to be able to update the app efficiently and automatically whenever there is a new patch available.
I saw this post which got me to take a look at WyBuild. It looks great and probably what I may end up using for the Windows version but what about Mac? What are some alternatives available to me?
I've just started developing a Qt-based autoupdater called Fervor for my own needs. You can try it out, contributions are more than welcome too.
For Mac the best choice is Sparkle used by WebKit, Adium, Cyberduck and more. Its only for Mac but I guess native look matters on Mac a lot.
Not familiar with WyBuild so cannot comment. Sparkle is a fine choice but the poster preferred a single app for both platforms. BitRock InstallBuilder contains an autoupdater written in Qt that can be used independently (disclaimer, I am the original BitRock developer). It is a commercial app, but we have free licenses for open source projects.
There is Updatenode which seems to provide a real Qt cross-platform solution.
It comes with a prebuilt client for Windows, Mac and Linux. The online service lets you manage updates very easy and are able to see good charts of your application usage.
And here another one of the possibilities:
Using the Qt Installer Framework: It provides installers for Windows/Linux/Mac with an build-in updater. If you need an example - The MaintenanceTool of your Qt-Installation uses the framework.
To get an auto-updater from it, all you need to do is:
Create an online installer (Just check the documentation, it's not that hard)
Use the maintenancetool in your application to check for updates.
This cane be done using my QtAutoUpdater. Go there for more information about the whole process
If new updates are available, the maintenancetool can be started in updater mode to install the update
Update the online repository - and your update is out.
Advantages:
Installer and updater in 1 tool - this means less work for you
Easy to use (with or without the QtAutoUpdater library)
Cross-Platform for all desktop platforms supported by Qt
The installer itself is a Qt original
Disadvantages:
No "native" installers (i.e. no .msi on windows or .deb on ubuntu)
Must be used together - if you want to use the update feature, you have to use the framework as installer
This may be obvious, but for Linux you can use the built in package manager. For example, apt-get, yum, pacman, or what have you.
I downloaded the qt embedded demo source code recently on my linux machine. Following are the outcomes during running of the program
I compiled it statically on my x86 machine and run the application on x86 machine it runs fine. But when i took the statically compiled binary file to other machine with Atom platform It run with some missing widgets. I found that the plugins cant be ported with static compilation. Can anybody tell me is it true? If no can anybody tell me the steps for it?
I compiled it dynamically with shared libraries. Then got an executalbe on linux. I did "ldd MyAppName". It show me the shared library files it is using. But I dont know how to package these. Can anybody tell me the steps to package it?
I checked in the article on deploying qt applications on X11-linux platforms. But its not complete. Can anybody give me the detailed steps?
Any help will be appreciated......
you either have a distro, that does'nt support atom, or libraries, that are not compiled with support for it. either way - something somewhere on your system (or your qt) is not compiled for atom
The problem is that you are compiling your app, and its libraries (static or dynamic) work for x86, not for Atom. Perhaps you are able to create some sort of fat binary (lipo?) so that pieces of your app will function on x86 and Atom, but bits using the x86-only libraries will not function on Atom. (Right? That's a concise definition of your problem?)
If you have the source code for the libraries that don't run on Atom, and they're important to you, you should consider porting the code to Atom. If it's open-source code, you can contribute to the project. While you didn't give many details, my (very generic) approach to this would be to get the code on an Atom machine, write a very short test application for the library, and work out the issues.
Re #2: There's little difference between compiling an app and linking to shared libraries or dynamic libraries. On your x86 machine, if you have this code (these "plugins") compiled as dynamic libraries, it's pretty much the same as statically linking those binaries into the app. These libraries will work on x86, whether they're dynamically or statically linked.
I'm not sure if that helps very much -- if you're getting binary Qt plugins as static or dynamic libraries without source, you're out of luck. Submit a bug report. If you have source code, you can do a lot more.
I just dynamically compiled my application and ported to atom platform. I found the dependencies and ported them also and set the environment variable LD_LIBRARY_PATH on target machine to my ported shared libraries and It worked. Thanks everybody for your suggestions
I come from UNIX world, I'm quite familiar with Linux, Solaris, Cygwin
and MinGW development. Recently I ported one of my
big projects (cppcms) to support MSVC,
including building static and dynamic libraries with CMake.
And I get all the time absolutely weird issues:
I had CMake build issues because Windows programming
lacks naming convention
for import and static libraries.
Now I discovered that I should use different versions of ICU (debug/release builds) according to the
actual build I do (Debug/RelWithDebInfo -- should use Debug ICU, Release release ICU) and so I should
change actual conventions for searching libraries according to debug/release mode only under MSVC.
Otherwise application just would not start giving a error on missing DLL.
I don't have any such issues under Mingw or Cygwin with GCC, Open Solaris with Sun Studio or Linux with gcc or intel compilers.
And I still have numerous wired issues and wired bugs and very strange behavior -- even some trivial things do not work
under MSVC builds, when everything works absolutely fine under Solaris/Linux/Cygwin/Mingw using GCC from 3.4 up to 4.4,
Sun Studio and Intel compilers). But not under MSVC.
To be honest, I have no idea how to deal with Last one! Because it looks like for me more like environment issues.
I know that the question is not really well defined. I think I'm quite experienced
developer and I know how to write portable and good C++ code. But using Microsoft native
tools drives me crazy with issues I just don't know how to solve.
Question: What should experienced Unix programmer with quite good base in Win32 API should know when it
starts using Genuine Microsoft Tools?
P.S.: Can someone explain why "Release With Debug Info" requires Debug version of MSVC runtime? And why there two versions of runtime exist at all?
P.P.S.: Please note I don't have issues with Win32 API, in fact Windows GCC build works absolutely fine.
Clarifications:
I'm looking for pitfalls that programmer that come from Unix world would may fall into.
For example, when moving from Linux to Solaris: make sure you compile code with -mt or
-pthreads when using multi threaded programs, linking with -lpthread is not enough.
P.S.: Can someone explain why "Release
With Debug Info" requires Debug
version of MSVC runtime?
It doesn't.
And why there
two versions of runtime exist at all?
Because the debug version does more error checking.
And I still have numerous wired issues
and wired bugs and very strange
behavior -- even some trivial things
do not work under MSVC builds,
* What am I doing wrong?
Not telling us what "wired issues and wired bugs and very strange behavior" you get.
* Where should I start?
By telling us the specific errors and problems you encounter.
* What do I miss?
Reading the documentation and learning the tools.
If your question is "What do I read to become a good Windows programmer?" then my answer is: Everything from Jeff Richter, as a start.
There is no magic bullet which will automatically make you an experienced Windows developer. Windows is a very different land compared to Unix. There are lots of quirks, weird behavior, and stuff which is just plain different. The only way to get out with your sanity intact is to tackle the transition one small problem at a time. Concentrate on a specific problem and try to understand the problem. Don't just "get it to work", but really understand what is happening. A good book about Windows programming will help.
There are huge amounts of Windows knowledge and experience accumulated in the SO community, but the only way to access it is to ask concrete questions about specific problems.
The release and debug versions of DLL's use different ways of allocating memory, that is why it is not advisable to mix release and debug versions. If you allocate something in a debug mode DLL and pass it back to the application which was compiled in release mode you may get into trouble.
In the case of your naming issues you may want to have different directories where you place your static / dll's. You can do do this in visual studio by using the configuration manager, not sure how it is under the express version.
I think you need to try and actually understand the new toolset rather than just try and squish it into your current understanding of your existing tools. For that, the best way, IMHO, is for you to try and start to use Visual Studio as Microsoft intended and then once you can build a simple project in the IDE you can move to building it using your preferred make system but do so with an understanding of how the IDE is using its make system to set things up for that build (which WILL work).
So, for example, for part 1 of your question you want to create a simple static library project and a simple dll project and look at the linker options tabs. Jump to the 'Command line' view and you'll see that a DLL uses the /OUT linker option to set the name and location of the dll file and the /LIB linker option to set the name and location of the import library. With a static library only the /OUT option is used and it indicates the name of the static lib. It's true that if you're building a static lib and a DLL from the same source and you have both the /LIB for the dll set to MyCrossPlatformCode.lib and /OUT set to MyCrossPlatformCode.dll then you may have problems if you also build a static lib with an /OUT switch of MyCrossPlatformCode.lib... Simply don't do that; either build the static libs to a different output directory (which is what OpenSSL does), or, better (IMHO), mangle the names somewhat so that you have MyCrossPlatformCode.lib/.dll and MyCrossPlatformCode_static.lib (which is what STLPort does).
Note that you might also want to mangle in (or account for) building with different versions of the Microsoft tool chain (so you might end up with stlport_vc8_x64d_static.5.1, perhaps).
An alternative approach, if you really can't face the thought of understanding your toolset, is that you could take a look at some of the popular open source systems that build quite fine on Windows and Unix systems; OpenSSL and STLPort for a start, perhaps.