I need to build my QT console application as 64 bit. i.e. x86_64
My config file looks like this:
CONFIG += qt console debug x86_64
CONFIG -= app_bundle
HEADERS = HelperClass.h
SOURCES = HelperClass.cpp \
main.cpp
The compile goes fine without issue. But, when the build gets to the link step, it complains that I don't have the Qt x86_64 architecture.
Excerpt from build:
ld: warning in /Library/Frameworks/QtGui.framework/QtGui, missing required architecture x86_64 in file
ld: warning in /Library/Frameworks/QtCore.framework/QtCore, missing required architecture x86_64 in file
Undefined symbols:
"QIODevice::getChar(char*)", referenced from:
...
Do I need to download the Qt source and build the required architecture for this to work? My install is from the provided binaries for Mac OSX - Qt 4.5.2 on the QT site. I'm guessing that build does not come with 64bit versions of the libraries. Am I correct?
The QT SDK does NOT include by default the 64 bit libraries in Mac OS X (I think it is strange but it is that way). For compiling my apps in x86_64 I just download the standalone libraries with Cocoa (32/64 bits) and I install them after the SDK is installed.
Everything works like a charm then.
From the Qt for Open Source C++ development on Mac OS X page it appears that the 32 and 64 bit libraries should be included:
Mac binary package using Cocoa for Mac OS X 10.5 (32-bit and 64-bit)
http://get.qtsoftware.com/qt/source/qt-mac-cocoa-opensource-4.5.2.dmg
If you are still having trouble you could try to download the source from the same page:
http://get.qtsoftware.com/qt/source/qt-mac-opensource-src-4.5.2.tar.gz
and configure with:
-arch x86_64
See http://doc.trolltech.com/4.5/developing-on-mac.html#universal-binaries
Note that the link above mentions that if no arch is specified it builds 32bit for the current platform.
You can check the libraries using "file":
$ file /Library/Frameworks/QtGui.framework/QtGui
/Library/Frameworks/QtGui.framework/QtGui: Mach-O universal binary with 4 architectures
/Library/Frameworks/QtGui.framework/QtGui (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64
/Library/Frameworks/QtGui.framework/QtGui (for architecture ppc7400): Mach-O dynamically linked shared library ppc
/Library/Frameworks/QtGui.framework/QtGui (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
/Library/Frameworks/QtGui.framework/QtGui (for architecture i386): Mach-O dynamically linked shared library i386
I see the same "ld warning: ... missing required architecture x86_64 in file" errors, so the error message is misleading.
Related
I am porting my C++ code from Linux to windows.
The code open a ttyACM*.
I am using MINGW64 for building code on Windows.
gcc generates an error that termios.h is not found.
Is there a MINGW64 library which supports Posix interfaces?
or should I switch to MSVC?
I have used OpenCV 3.2.0 since a long time ago.
Recently, I need to implement face detection with landmark detection so I decided to build the OpenCV again with extra OpenCV modules.
However, it seems that OpenCV 3.2.0 is not compatible with the latest extra OpenCV modules so I have to build it with the latest OpenCV (which is 4.0.0)
The problem is, I'm in a Catch 22 situation.
1. If I use mingw 32bit 5.1.0 to build OpenCV (which is a compiler bundled with Qt), I have a following error
CMakeFiles\opencv_core.dir/objects.a: member
CMakeFiles\opencv_core.dir/objects.a(vs_version.rc.obj) in archive is
not an object
2. If I use mingw 64bit 8.1.0 to build OpenCV, it works fine. However there are two situations that give me an error.
2.1. If I use mingw 32bit 5.1.0 to build a Qt Project with those OpenCV libs, it gives a following error.
D:\opencv-build\bin\libopencv_core400.dll:-1: error: file not
recognized: File format not recognized
I suspect that this has something to do with 32-64bit problem. The compiler may expect 32bit libs, but the libs are 64bit format because the compiler used to build OpenCV was 64bit mingw.
file format pei-i386
file format pei-x86-64
The first one is the file format of the OpenCV 3.2.0 libs which I used in the past and worked fine with Qt.
The second one is the file format of the OpenCV 4.0.0 libs newly built.
2.2 If I use mingw 64bit 8.1.0 to build a Qt Project with those OpenCV libs, it gives a following error.
collect2.exe: error: ld returned 5 exit status
I suspect that this occurred because basically Qt is for 32-bit, not 64-bit.
What I want to do is that building OpenCV 4.0.0 so that somehow the file format of those OpenCV libs is pei-i386, not pei-x86-64.
How can I achieve this?
I want to run a program which needs Qt5.8 libraries, and the underlying OS is Ubuntu 14.05.5 LTS
This OS seems to include a prebuilt package for Qt 5.2.1 and nothing later in the repos.
Can I safely add Qt5.8 libraries? How would I do so? (I can only find instructions for installing the full Qt IDE)
As per my information, Binaries (or offline/online installers) for installing Qt (>= 5.6) on 32-bit linux are not provided. For example, If I want to use Qt 5.9.0 on 32-bit linux (debian, specifically), the only option is to download Qt source and build it. I have successfully built Qt 5.9.0 on my 32-bit linux machine. But I have to do this on all my development PC's. Instead if I can build it once and create an installer somehow, that will save a lot of time. Is there a way to create offline installer (e.g. *.run files) for installing Qt 5.9.0 on 32-bit Linux (e.g. debian)?
As stated by #Velkan, Qt is available on 32 bit Debian from the official repos.
But, indeed, there is no 32-bit Linux installer from the Qt project.
Regarding copying a Qt install from a Debian PC to another, you do not need to create an installer. Just copy/tar/zip the directory in which Qt is installed. The only requirement is that you must keep the installation in the same absolute path as the Qt Core library has the path hardcoded in it and it is use for plugin detection.
NB1: It is possible to patch Qt Core library to change the hardcoded path and even make it relative. It is not officially documented but you can take a look in the sources of tools like windeployqt or the online installer
NB2: Do not use Qt 5.9.0, prefer 5.9.2. Both are forward and backward binary compatible, but the latter received bug fixes.
I've downloaded the source for QT 5.6.0 and I'm attempting to compile/install it on a Cygwin installation for Windows.
The Cygwin build already has Qt4 and Qt3 libraries installed. Trying to upgrade so I can install the latest QtCreator suite.
Here is my Cygwin version via uname -a:
CYGWIN_NT-10.0 J_Mick-Windoze 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64 Cygwin
When I try to compile QT 5.6.1 via running ./configure -platform cygwin-g++ -prefix $PWD/qtbase -opensource -nomake tests I get the following error:
Running configuration tests (phase 1)...
Done running configuration tests.
Creating qmake...
.In file included from /home/JasonMick/Install_Stuff/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtCore/5.6.0/QtCore/private/qcore_unix_p.h:1:0,
from /home/JasonMick/Install_Stuff/qt-everywhere-opensource-src-5.6.0/qtbase/src/corelib/global/qglobal.cpp:90:
/home/JasonMick/Install_Stuff/qt-everywhere-opensource-src-5.6.0/qtbase/src/corelib/kernel/qcore_unix_p.h: In function ‘key_t qt_safe_ftok(const QByteArray&, int)’:
/home/JasonMick/Install_Stuff/qt-everywhere-opensource-src-5.6.0/qtbase/src/corelib/kernel/qcore_unix_p.h:333:12: error: ‘::ftok’ has not been declared
return ::ftok(filename.constData(), qHash(filename, proj_id));
^
make: *** [qglobal.o] Error 1
Now clearly there is support for cygwin in the QT project as grepping inside configure I see the platform:
PLATFORM=cygwin-g++
...is defined. Doing some reading I read that ftok is a part of the IPC group of shared memory functions. One link regarding a similar error with a different app suggested linking in -lcygwin. I successfully added this to the L_FLAGS variable in the configure file, but it's still giving the same error, even when I specify the Cygwin as the platform via the -platform flag.
I would appreciate any advice as to how to get rid of this issue -- which I believe is attributable to some sort of missing IPC library error.