I need to call qmake in one of the make target commands. The question is how can I figure out which qmake has been called when executing this qmake. Like when in a bash script you ask for the executable.
Obviously I'm in an environment with multiple Qt installations, including defaults of Ubuntu 14.04 and qmake is the decider of which libraries are going to be fed into compilation (I'm not 100% sure on the later).
Any help is greatly appreciated!
I think this might be what you're looking for: http://doc.qt.io/qt-5/qmake-language.html#accessing-qmake-properties
$$[QT_INSTALL_BINS]/qmake should be the path.
Simply add a line that prints the version:
qmake --version
Related
I am trying to run the metal executable from my zsh terminal in order to meta-analyze GWAS data. I have the executable in the correct directory and have checked that it is not 0MB due to truncation.
Reproducible:
Download the Linux file from http://csg.sph.umich.edu/abecasis/metal/download/
In terminal:
PATH TO EXECUTABLE ./metal
zsh: exec format error: ./metal
You probably install wrong OS of go, for example, you might install go for MacOS in Linux
I solve this problem by installing go for correct OS
The executable has been pre-compiled on a certain distribution with libraries at a certain places at certain versions.
If you have a different distribution, libraries versions, it won't work and you better compile from the source.
Basically what you have to do is to download and extract the sources, go in the folder and execute make. (You will have probably to install make first.)
I think that's not your job at all so maybe you can find a geeky person to help you, because you may stumble upon problems, libraries to install, old versions not supported anymore, new versions not supported yet...
It happened to me when I emptied an executable by mistake.
~>true > a
~>wc -c a
0 a
~>./a
zsh: exec format error: ./a
I am a little bit confused on how to efficiently prepare the R package, so that it will be compatible across all needed system platforms. This is needed so that the new version of package will be accepted by CRAN. The main difficulty comes from compiling external C++ shared library, and optionally CUDA version if the compiler is available. To support this flow I've created specific Makefile, unfortunately using GNU-extensions. It works fine on Linux, OSX and when executed manually via gmake on Solaris. Relevant part is here:
# Checking whether nvcc compiler is available
NVCC_TEST = $(shell basename $(shell which nvcc 2> /dev/null)"")
ifeq ($(NVCC_TEST),nvcc)
ALL_LIBS += libcucubes_gpu.so
ALL_OBJS += $(GPU_OBJS)
ALL_FLAGS += $(GPU_FLAGS)
else
ALL_OBJS += gpu_fallback.o
endif
Turns out that, when running R CMD INSTALL (...) on Solaris, the installation fails on something like this:
make: Fatal error in reader: Makefile, line 39: Unexpected end of line seen
ERROR: compilation failed for package 'libcucubes'
As it turns out, it is caused by the fact that Solaris' version of make is executed instead of GNU-compatible gmake (I've tested it works fine), even though it is available. My question is whether there is any simple way to force usage of gmake here, for the R package build. In general I know I could use autotools to solve compatibility issues during installation, but it seems to bring too much complexity for that simple case. Any advices will be really appreciated, thanks!
If you can't get your build process to use gmake instead of Solaris's pure POSIX make, you can use this hack:
Make a dedicated directory for this hack: mkdir $HOME/make_hack
Softlink gmake asmakein that directory: ln -s /path/to/gmake $HOME/make_hack/make
Set your PATH: PATH=$HOME/make_hack:$PATH
Now, run your build process using that PATH, and it should use gmake. Hopefully it just uses make from its PATH envval and not some hardcoded full path.
Yeah, it's a hack. But it's probably a lot easier than modifying the build process to use gmake instead of make.
From Writing R Extensions:
If you really must require GNU make, declare it in the DESCRIPTION
file by
SystemRequirements: GNU make
and ensure that you use the value of environment variable MAKE (and
not just make) in your scripts.
configure scripts are the preferred solution though. BTW, in general a Makevars file is also preferred over a full Makefile.
For a couple of reasons we need the ability to run lupdate on our sources, run a script on the resulting ts files, and then run lrelease. We're using CMake for our builds so a CMake macro would be nice.
But the only ones I see either just run lrelease, or run lupdate followed by lrelease. Is there one I'm missing to just run lupdate?
Thanks.
You should use this guide:
https://gitlab.kitware.com/cmake/community/-/wikis/doc/tutorials/How-To-Build-Qt4-Software
You could add some options in CMake to call only 'lupdate' depending on your requirements.
Note that QT4_ADD_TRANSLATION must be changed to QT5_ADD_TRANSLATION if you are working with Qt 5.
I am trying to cross compile Qt with WebKit for an embedded arm device (freescale processor). I have a arm-none-linux-gnueabi toolchain.
Qt actually compiled, but I have run into problems when trying to compile the demos, in particular the WebKit ones, which is really what I am after.
The first problem I was having was that libjscore was not found, which was an error due to the way Qt handles static builds. Turns out you can copy the library and it works, see here.
Now compilation breaks again saying it can not find libpthread.so.0, which would seem to be a toolchain problem rather than a Qt problem.
Searching the directory tree in my toolchain, there are several libpthreads. A copy of the find | grep libpthread command's output is below for reference.
./arm-none-linux-gnueabi/sysroot/vfp/lib/libpthread-2.5.so
./arm-none-linux-gnueabi/sysroot/vfp/usr/lib/libpthread_nonshared.a
./arm-none-linux-gnueabi/sysroot/vfp/usr/lib/libpthread.a
./arm-none-linux-gnueabi/sysroot/vfp/usr/lib/libpthread.so_orig
./arm-none-linux-gnueabi/sysroot/vfp/usr/lib/libpthread.so
./arm-none-linux-gnueabi/sysroot/lib/libpthread-2.5.so
./arm-none-linux-gnueabi/sysroot/usr/lib/libpthread_nonshared.a
./arm-none-linux-gnueabi/sysroot/usr/lib/libpthread.a
./arm-none-linux-gnueabi/sysroot/usr/lib/libpthread.so_orig
./arm-none-linux-gnueabi/sysroot/usr/lib/libpthread.so
So it seems that there is something weird with the linker? Also, what needs to be symlinked to create the libpthread.so.0?
Note: the _libpthread.so_orig_ and libpthread.so follow this fix.
Any help or suggestions are much appreciated. I've been banging my head against a wall for two days now.
Thanks
In general, you should make sure that the toolchain you built (or has been built for you) is in the same exact path it was built at. The libraries (*.so *.a) should also be in the same original path. It should look like this:
<path>/bin
<path>/usr/lib
<path>/lib
Those folders should not be moved. The toolchain executables are in "bin" and the libraries it looks for are in "../usr/lib and ../lib". Also, <path> may be hard-coded into your gcc binaries in some fashion. Moving it around seems to break things.
Target is a raspberry PI
I copy target lib directory to myuserdirectory
target /usr/lib to my crosscompiler /usr/lib/ directorie
target /lib my crosscompiler /lib/ directorie
I create two symbolic link:
ln -s /yourcrosscompilerusrlibdirectory /usr/lib/arm-linux-gnueabihf
ln -s /yourcrosscompilerusrdirectory /lib/arm-linux-gnueabihf
and it's work for me
libpthread are in /yourcrosscompilerusrlibdirectory
After installing Qt SDK for Open Source C++ development on Mac OS by following the respective steps
Note for the binary package: If you have the binary package, simply
double-click on the Qt.mpkg and follow the instructions to install Qt.
Yes, that is all I have done to install Qt on MacOsX. Everything was going fine, until I run a sample application, of which compile output resulted in:
No valid Qt version set.
Set one in Preferences
Error while building project qtilk
When executing build step 'QMake'
Canceled build.
Then I tried to change the respective Qt version in Preferences and I hovered over the Path, I realized my mkspec isn't set:
Then I tried querying qmake by qmake -query:
QT_INSTALL_PREFIX:/
QT_INSTALL_DATA:/usr/local/Qt4.6
QT_INSTALL_DOCS:/Developer/Documentation/Qt
QT_INSTALL_HEADERS:/usr/include
QT_INSTALL_LIBS:/Library/Frameworks
QT_INSTALL_BINS:/Developer/Tools/Qt
QT_INSTALL_PLUGINS:/Developer/Applications/Qt/plugins
QT_INSTALL_TRANSLATIONS:/Developer/Applications/Qt/translations
QT_INSTALL_CONFIGURATION:/Library/Preferences/Qt
QT_INSTALL_EXAMPLES:/Developer/Examples/Qt/
QT_INSTALL_DEMOS:/Developer/Examples/Qt/Demos
**QMAKE_MKSPECS:/usr/local/Qt4.6/mkspecs**
QMAKE_VERSION:2.01a
QT_VERSION:4.6.2
QMAKE_MKSPECS seems to be set here??
Will setting my mkspec solve my building problem? I tried setting by typing export mkspec=macx-g++. Still, mkspec seems not to be set to anything. I am all ears waiting for your answers. Thanks in advance.
To set the correct spec, use:
qmake -spec max-g++