On its website OpenFlipper says it can be compiled in three steps as:
cd build
cmake ..
make # or, even better, make -j8
However I get an error saying Qt is unable to be found at the cmake step and that I should specify a QT5_INSTALL_PATH. However even if I do this OpenFlipper is still issuing the same complaint!
You are not supposed to specify where Qt is installed in the QT5_INSTALLED_DIR but prior to that as environment variable in your terminal:
# assuming Qt was installed in your home directory, as is default
export CMAKE_PREFIX_PATH=~/Qt5.7.0/5.7/gcc_64/
# note that you now have to call cmake etc from that process
Compiling and running it after that you might get errors telling you GL_ARB_vertex_buffer_object is not present, even if your glxinfo | grep ARB_vertex_buffer is telling you it is.* Clicking "Ignore" results in a crash. To mitigate this, you have to manually change (4,3) to (3,0) in
OpenFlipper/widgets/coreWidget/CoreWidget.cc
If you still experience errors, try deleting your cmake cache, this is accomplished by using cmake-gui (was in the package cmake-qt-gui for me) and hitting "Delete Cache"
(optional) remove the very annoying warning message you get at every start of OpenFlipper by removing the line concerning "renderers shipped" in
OpenFlipper/Core/Core.cc
*: My teaching assistant told me that there is a bug in Qt (<5.9) that forces OpenFlipper to use the OpenGL Compatibility Profile. Additionally Intel and AMD drivers hand back an OpenGL 3.0 Core Context when asked for an OpenGL 4.3 Compatibility Context (my TA described this behavior as a "bug", I'm not so sure about this), leading to a crash in Qt. So this should be resolved in Qt 5.9 (not out yet). This seems to affect also mainly integrated graphics, so one could try using a dedicated GPU.
Related
I have tried a lots of advice to help to set up the CDB debugger in Qt Creator but when using it that thing still takes ages to load up local variables.
My setup:
Windows 10 64-bit
Qt 5.6 (installed with sources)
Qt Creator 3.6.1
Microsoft Visual Studio 14 (2015) (both 32-bit and 64-bit compilers)
Windows SDK (for debugging tools = CDB)
The General tab in Options->Debugging lists auto-detected sources:
Source: Q:/qt5_workdir/w/s
Target: C:\Qt\5.6\Src
My symbols server and cache are set up in CDB Paths like this:
srv*http://msdl.microsoft.com/download/symbols
cache*C:\Qt\CDB-symbols-cache
On first run of the debugger it populates this directory with 70mb of (presumably downloaded) data but it does not seem to change afterwards on subsequent runs.
I suspect either the sources being loaded takes a long time (although I have a SSD) or that the CDB is re-downloading the symbols instead of using the cache. Any advice?
EDIT: As per request, result of .sympath command on my system:
Symbol search path is: srv*
Expanded Symbol search path is: cache*;SRV*https://msdl.microsoft.com/download/symbols
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred
srv*
I had the same problem with QtCreator 4.12 which was solved by removing AppData\Roaming\QtProject\default.qws as suggested by Abstraction in the comments above.
I had the same issue with QtCreator 4.0.2 and VS 2015. Here is what I did.
Downloaded the microsoft symbol package from symbol packages
Copied it to a local folder(D:\Symbols)
In QtCreator , Tools->Options->Debugger->CDB Paths select "Insert Symbol Server" and select the local folder. Will look like the below screen.
I tried all the above and did not worked, however one thing worked: renaming the file default.qws
Usually it would take 10 seconds to load the debugger and it went to 10 minutes. Analyzing deeper I found out that the problem is with the breakpoints: if a breakpoint is on a file which is not part of the project, the debugger attempts to resolve the breakpoint for each loaded module/DLL, making the process incredibly slow.
The solution is to edit the file default.qws and remove those breakpoints which are set to files that don't exists anymore and you will get the speed as before.
I'm trying to set up pocl-0.11 on an ARM (llvm-3.3). I used ./configure --enable-debug --disable-icd --enable-testsuites=all (I'd like to get pocl to run without ICD loader as a first step).
During configure I got a couple of warnings about disabled tests due to missing glut, libDSL, boostlib, etc. Since the warnings 'only' concern some testsuites, I assume the configure is fine and I guess some basic tests will still be enabled!?
Furthermore I get the output:
checking LLC host CPU... cortex-a9
configure: using the ARM optimized kernel lib for the native device
<stdin>:1:19: error: 'test' declared as an array with a negative size
constant int test[sizeof(long)==8?1:-1]={1}; (Is that relevant? I don't really know what to do with this message.)
Eventually configure succeeds and make & make install run without any hint of a problem.
make check then fails all tests, even: check for pocl version FAILED (testsuite.at:29)
The 001/testsuite.log file indicates a linker problem!?
Do you have any idea?
Am I missing a configure flag or an environment variable? I didn't touch --prefix or any other paths.
LLVM 3.3 is quite old and its support will be dropped after the next pocl release. The configure error message you see probably means it fails to detect your CPU features correctly, but the testsuite error indicates that not all LLVM symbols are properly linked in. You can try fixing this by using a shared LLVM library, but I really suggest you to upgrade LLVM. The upcoming 3.7 should work now and has fixed several issues and includes better OpenCL C Clang support.
We have been using Xcode 4 and LLVM 2.0 for a couple of months now and after finishing a huge update to our application we thought we would send it off to Apple.
What we couldn't imagine however, was that although the program was able to be built for both the simulator and devices, when it came to archiving, XCode just threw a nasty linking error and left us hanging there.
The error is related to the ZipKit library (we previously discussed the issues we had with making it work under XCode 4).
This is what we get:
ld: library not found for -ltouchzipkit
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang failed with exit code 1
So the question is: do we need to change any settings for an app that builds fine to be able to get archived as well?
Not trying to be flip, but it looks like the problem is that the linker can't find a library called "touchzipkit". The fact that this problem only comes up when you archive would seem to indicate your target has (at least one) build setting that has different values for "debug" and "release"... and that the "release" value is broken.
Not being familiar with ZipKit, I'm just shooting in the dark here. But I'd start checking out your build settings one by one, paying particular attention to library search paths and compiler flags where the debug and release settings are different.
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++
I installed Windows 10 (64bit). Since then, Isabelle HOL is no longer starting, even after a re-installation (which ran through smoothly). The error message is the following: "Startup Error: Error starting Java VM". This happens with the two versions I tested (2013-2 and 2015).
The jvm.dll which is specified in the configuration file, exists in the right folder. Additionally, I have installed Java SDK in newest version (8.51) in both, 32bit and 64bit.
Is there a known compatibility problem with Windows 10? Isabelle used to work with Windows 7 and 8.
Thank you for you help.
Update (150822)
From the developer's mailing list, there's a link to a test release:
NEWS: updated to jdk-8u60, with support for x86_64-windows
www4.in.tum.de/~wenzelm/test/Isabelle_21-Aug-2015
That's working different from Isabelle2015, in how it does some things with paths, so it might find the things it needs for Windows 10, or it may not. However, even if it works, there may be some incompatibilities with Isabelle2015 (in theorem proving).
Regardless, Isabelle only gets released 1 to 2 times a year, and I wouldn't expect anything special to be released for Windows 10 within 4 to 6 months. The links above, though, show that M.Wenzel can package together a test release, but he mainly operates on the user's mailing list.
In my batch file below, I set HOMEDRIVE and HOMEPATH, which you don't need if you want .isabelle to be in C:\user.
In this test release, those settings don't affect my home path. It also appears that USER_HOME is used, though my setting of USER_HOME doesn't make my batch file work for this test release.
Anyway, this test release has changed the way it works to discover things, and accomodates Windows even more, as shown by the new behaviour of the function File.platform_path.
It's working different enough, and requires enough changes, that I should stay with Isabelle2015, or I'll be out of sync with the official release.)
Original
(Zeroeth: Problems like this generally get hashed out on the mailing list, but I go ahead show you how I start Isabelle using a batch file, which I started doing before I had to start doing it.)
First, the Java that Isabelle uses is in this folder:
Isabelle2015\contrib\jdk\x86-cygwin\jre
Doing a normal Java install for Windows is not going to change which Java that Isabelle uses.
Below, I give you a batch file and bash file to start Isabelle/jEdit, which is an alternative to using Isabelle2015\Isabelle2015.exe.
For myself, what I've done is manually replace the 32-bit jre folder shown above with the jre in jre-8u45-windows-x64.tar.gz. (I renamed the old 32-bit folder. The most recent Java tar files can be found at the download page.)
Consequently, if I try to start up Isabelle with Isabelle2015.exe, I also get a popup that says, "Startup Error, Error starting Java VM", but starting Isabelle with the batch/bash combination works for me on Windows 8.1.
What I show you below may not fix your problem, but I guess Isabelle2015.exe has to get some info from the OS to work right, and maybe that's changed with Windows 10:
https://lists.cam.ac.uk/mailman/htdig/cl-isabelle-users/2014-December/msg00033.html
You put the batch and bash file below in the folder that you have or want your .isabelle folder. Change ISAHOME below to where your Isabelle distribution is. PATH needs the Cygwin bin in the path, and the path for isabelle, which I set in the batch file.
FILE: start-isabelle.bat
:: Isabelle2015.exe uses these directly. Setting HOME or USER_HOME doesn't work
set HOMEDRIVE=%~d0
set HOMEPATH=%~p0
:: Cygwin uses HOME, and this is how HOME is set in Cygwin-Terminal.bat
set HOME=%HOMEDRIVE%%HOMEPATH%
:: ADD PATHS: 'cygwin/bin' to start terminal, 'Isabelle2015/bin' for 'isabelle'
set ISAHOME=E:\E_2\d ev\Isabelle2015
set PATH=%PATH%;%ISAHOME%/contrib/cygwin/bin;%ISAHOME%/bin;
set CHERE_INVOKING=true
::MINTTY CONSOLE
start /MIN mintty.exe -i /Cygwin-Terminal.ico "%~dp0start-isabelle.bash"
:: REGULAR WINDOWS CONSOLE
::bash --login -i "%~dp0start-isabelle.bash"
FILE: start-isabelle.bash
#!/usr/bin/env bash
#
isabelle jedit -l HOL
With 64-bit Java, I can increase the size of the memory that Isabelle uses, by making this change in .isabelle\Isabelle2015\etc\settings:
JEDIT_JAVA_OPTIONS="-Xms1g -Xmx4g -Xss4m"
or
JEDIT_JAVA_OPTIONS="-Xms1024m -Xmx4096m -Xss4m"
With 32-bit Java, when I do that, Isabelle will start but then terminate.