TLDR:
VMWare virtual machine, Centos 5.6, gcc 4.8.1, Qt5 fully compiled.
Any Qt5 compatible QtCreator refuses to work due to the lack of opengl. Need help either making it work or advice on how to cross compile from Centos 6 to Centos 5 or on how to set up some other app to work with Qt5 code.
Detailed:
In a bit of a bind here - we have an app that is deployed to Centos version 5.6. It's quite old but upgrading is out of the question atm. It wouldn't be a problem but for 1 thing - I compile stuff for it on VMWare virtual machine and the linux kernel of this machine is too old to support vmgfx and provide OpenGL for versions of qtcreator that actually support qt5.
Its not that critical of a problem - I could always copile from command line, but I don't want to lose an ability of double clicking compilation errors to jump to file I need to edit. I don't do a lot of code editing on Centos obviously, but sometimes some errors are produced that are not present on Ubuntu or Windows and debugging/fixing them through command line will be too much work.
So far I see some choices I can take but I an not very familiar with either of them
1) Cross compile from fresher Centos distro. How do I do that, is that possible?
2) Use some other application to make fixes in my code. Is there anything that is reasonably possible to install to work with qt5 toolchain?
3) Somehow fix qtcreator 2.5 to work with qt5 versions (so far internet says me it's not possible)
4) Maybe somewhow circumvent lack of opengl to launch qtcreator 3?
Related
I'm stuck in a deployment issue with my Qt 5.4.0 application.
After two days of research, my app really doesn't want to execute on Windows XP !
I have created my deployment folder with windeployqt provided by my Qt installation. When I double-click on *.exe, I have always :
The procedure entry point vsprintf_s could not be located in the dynamic link library msvcrt.dll.
Dependency walker hasn't really helped me and I don't know what I can try now.
Note :
SDK : Qt 5.4.0 (MSVC 2010, 32 Bits)
IDE : QT Creator 3.3.0
Compiler : MinGW 4.9.1 32 Bits
Need to run on : Windows XP Pro SP2 32 Bits
App works like a charm on Windows 7 with same configuration (IDE, compiler, etc.)
While Guilhem G. is correct in the broader sense, it doesn't mean you actually called that function yourself (speaking now to a theoretically other person running into this issue like me, heh). I believe it's a bug with MinGW's XP support; I've seen bug reports of similar issues, including nearly the exact same issue in a much earlier version of Qt that was then fixed. I haven't seen this particular incarnation, which I actually ran into myself. I suppose I should probably submit a bug report!
Anyways, I've fixed it without changing any of the code I've written myself. What I had to do to fix it was twofold:
Switch over to using the msvc2010 compiler, since that set of C++ libraries rather unsurprisingly runs fine on Windows XP (AFAIK they still haven't dropped XP support with the latest version).
Switch over to Qt 5.5 (I'll explain why at the end).
For the compiler, you'll need then either Microsoft Visual Studio 2010 (hence the name), or the older Windows SDK that ships with it; the "Microsoft Windows Software Development Kit for Windows Server 2008 and .NET Framework 3.5" release should do the trick for you if you don't have a Visual Studio 2010 license.
Once one of those is installed, I'd encourage you to install Qt 5.5 as compiled by MSVC2010. You can either start a fresh installer or use the Qt Maintenance Tool which should already be installed.
Once that kit is installed, within your project (selecting "Projects" from the left-side menu) you should be able to go "Add Kit" and select Qt 5.5 msvc2010 32-bit, and if you now recompile and redeploy your application, it should run fine on XP.
Now, why did I insist on you upgrading to Qt 5.5? Well, there's some underlying issues with choosing a working OpenGL renderer on each version of Windows, and Qt 5.5 simplifies that a lot by having it fall back on OpenGL or ANGLE depending on what capabilities are actually detected, plus IIRC some other related fixes. So certainly if you're deploying a QML / Qt Quick 2.0 app across multiple Windows versions like I'm doing, it's worth upgrading to Qt 5.5.
The error was I called "sprintf_s" somewhere in my code (ok for recent windows on my dev machine but not for XP).
If you have the same problem when you search in your code don't use exactly the name of the function in the error message but an expression like *_s.
You probably call a secure API function somewhere !
I've got some experience in programming for Windows environment but I need to develop a "Kiosk" (I've heard that this is the right name) on a BeagleBone Black. I'm totally new to Linux and also new to the tools I'm going to use. Until the last couple of months, I developed with VB6 and C++Builder only.
Right now I have Eclipse, MinGW and wxWidgets working on my Windowns 7 64-bits PC, and the BeagleBone Black booting a Debian 7.8 with LXDE.
I need to setup a tool-chain to compile for the BeagleBone Black. I tried really hard and have read at least hundred pages, but still I've not figured it out.
From This Site I've learnt that it's possible to compile for Linux from Windows, which could be the perfect solution. If not possible, I already have a Virtual Machine running Ubuntu (but I can change it if needed) ready for Eclipse and other stuff installation.
I'm still lost about what tool-chain to use/build with. This site seems to have already built a tool-chain, but there's no indication to where to go from there. I understand that I should now compile the wxWidgets with this tools, but I'm unsure and also I don't want to mess-up my current working setup in Windows 'cause I missed a switch or a path.
I see how this question was asked more than one time, but I didn't find one that is up-to-date so I'm asking it again.
How to make a tool-chain to compile a GUI application, from Windows using Eclipse, MinGW and wxWidget for a BeagleBone Black running Debian and LXDE?
You need a compiler that runs on Windows and produces binaries for the target platform (Debian arm).
You need a SDK (headers, libs) for the target platform.
The MinGW-64w wiki describes how to build MinGW cross-compiler and build environment.
You can also look at SO: C++ cross-compiler from Windows to Linux.
Another technique is Canadian Cross, like Google makes its Android NDK for Windows host. At first you should setup Linux build machine. Then build GCC and binutils that will run on Windows machine and will produce binaries for Debian arm. Then copy built toolchain to Windows Cygwin or MSYS environment.
My experience with C++, GCC, MinGW and Cygwin is very limited. However, I already tested it and realized that Cygwin is not the ideal solution for what I am trying to do. Even though a GTK+ program with GTKWebkit works fine on Cygwin, it's not that great in terms of packaging the final project to a single .exe. The dependency on the cywin1.dll, etc... is a deal breaker.
I tested MinGW and it works flawlessly for a standard GTK only application in Windows. And the file size is great!
I tested a standard GCC compiler to compile a GTK & WebKitGtk application on Mac and it worked flawlessly.
But in the windows world where I am getting confused with GTK and WebkitGTK. What I want to do is compile a sample WebkitGTK application on Windows using MinGW. So, all the required libraries are statically linked and has a single .exe.
What are my choices? How do I actually build WebsiteGTK on Windows? Please give me the tools and as much details as you can.
FYI, QtWebkit is not going to cut it. Their licensing terms are not that commercial friendly.
I never did get WebKitGtk to compile on Windows. I think I could have got it to work using cygwin, but that's a non-starter for the project I'm working on.
I ended up using Chromium Embedded Framework instead: https://code.google.com/p/chromiumembedded/. It has clear instructions and sample apps for Mac, Linux, Windows, and mobile.
Here someone says that the easiest way to do that it's to cross-compile from virtual machine. Actually, there is binary there.
He uses OpenSUSE booted through VirtualBox. Then, using osc tool, get the mingw32-webkitgtk from windows:mingw:win32 and build it with osc.
Can someone suggest free VoIP library(C/C++) for Linux? All libs that I found are outdated and won't compile on my Ubuntu 12.10 box. I have tried OPAL, Sofia, PJ - can't get working anything.
Well, I've gotten PJ to compile and run on Ubuntu 10.04 and 12.04 (32 bit). Also Linphone and GStreamer. I'm guessing your environment needs a clean-up or some additional stuff in it. Liknphone, in particular, took several upgrades with bleeding edge packages.
So, please pick one and compile it and tell us what happens. The configure script's log might be a good thing to attach to your reply. Perhaps, also, the output of the make you run after configure,
This question may seem blindingly obvious and I realise I am putting myself up for a large number of downvotes but I am very new to Linux dev and have only been working on it for a while.
I have been writing an application on ubuntu 12.04 (kernel 3.2.0) in C++ then copying this via scp to an ubuntu 8.04 (kernel 2.6.30) installation on another device. I have been noticing some very strange behaviour that I simply cannot explain. I have naively assumed that I can run this executable on a previous version, but it is beginning to dawn on me that this in fact may not be the case. In future must I ensure that the Linux version I build my application on is identical to that which it will be running on in the field?? Or must I actually build the application from source code directly on the device it will be running on??? I am very new to Linux dev but not new to C++ so I realise that this question may seem facile, but this is the kind of issue that I have simply not seen in books/tutorials etc.
Most of the time, it's not the kernel that stops you, it's glibc.
glibc is backwards compatible, meaning programs compiled and linked to an older version will work exactly the same with a newer version at runtime. The other way around is not that compatible.
Best is of course to build on the distro you want to run it. If you can't do that, build on the one with the oldest glibc install.
It's also very hard to build and link to an older glibc than the system glibc, installing/building glibc tends to mess up your system more than it's worth. Set up a VM with an old Linux, and use that instead.