Using the Memcheck function of Qt Creator returns the following:
valgrind: Bad option: --xml=yes, but no XML destination specified
valgrind: --xml=yes has been specified, but there is no XML output
valgrind: destination. You must specify an XML output destination
valgrind: using --xml-fd, --xml-file or --xml-socket.
valgrind: Use --help for more information or consult the user manual.
Analyzing finished.
** Unknown error **
Is there something in the configuration that hasn't been set properly, or is this a Qt Creator bug? I can't see anywhere in the settings where I could possibly inject a command line argument or set the XML file output.
It's due a xml-socket bug in valgrind-3.13.
For now, you can downgrade to valgrind-3.12 if you want to use valgrind without any problems.
Related
I'm trying to install frama-c on my distro of manjaro 18.1.5, but no matter what I try, I always have an error.
First I tried to install via the AUR, and it seems to work, but when i try to open a file from the gui, it fails and says something like "invalid user input" even though I use files that works on a known good install.
Edit: here is the error output for this file:
[kernel] Parsing max.c (with preprocessing)
[kernel:annot-error] max.c:2: Warning:
unbound logic variable INT_MIN. Ignoring logic specification of function max
[kernel] User Error: warning annot-error treated as fatal error.
[kernel] User Error: stopping on file "max.c" that has errors. Add '-kernel-msg-key pp'
for preprocessing command.
Then I tried to install it using opam, so I first try to install dependencies with depext but it does not install anything then when I tried to install frama-c, it fails with the following error :
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[ERROR] The compilation of frama-c failed at
"/home/benoit/.opam/opam-init/hooks/sandbox.sh build make -j7".
#=== ERROR while compiling frama-c.20.0 =======================================#
# context 2.0.5 | linux/x86_64 | ocaml-system.4.09.0 | https://opam.ocaml.org#2d21a0b6
# path ~/.opam/default/.opam-switch/build/frama-c.20.0
# command ~/.opam/opam-init/hooks/sandbox.sh build make -j7
# exit-code 2
# env-file ~/.opam/log/frama-c-4880-6d07ae.env
# output-file ~/.opam/log/frama-c-4880-6d07ae.out
### output ###
# [...]
# Ocamlopt src/plugins/value/legacy/eval_terms.cmx
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_transfer.cmx
# Ocamlopt src/plugins/value/legacy/eval_annots.cmx
# Ocamlopt src/plugins/value/engine/transfer_logic.cmx
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_domain.cmx
# /usr/bin/ld: cannot find -lgtksourceview-2.0
# collect2: error: ld returned 1 exit status
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_specification.cmx
# File "_none_", line 1:
# Error: Error while building custom runtime system
# make: *** [Makefile:1294: bin/viewer.byte] Error 2
# make: *** Waiting for unfinished jobs....
My final attempt was to build it from source, but the make fails with the following error :
Ocamlc src/plugins/server/jbuffer.cmo
File "src/plugins/server/jbuffer.ml", line 23, characters 12-26:
23 | type json = Yojson.Basic.t
^^^^^^^^^^^^^^
Error: Unbound type constructor Yojson.Basic.t
make: *** [share/Makefile.generic:78: src/plugins/server/jbuffer.cmo] Error 2
My only remaining solution is to use a VM with debian but it's really ideal for me...
Does anyone have an idea of what i could do?
Thank you!
There are multiple issues in your question, and I believe some of them are worthy of investigation as possible bugs or issues. I'd recommend trying one of the official Frama-C support channels:
Creating an issue in the Frama-C Gitlab public repository;
Or creating an issue in the Frama-C Github snapshot repository (currently being deprecated in favor of the Gitlab repository, which is updated daily);
Or trying some interactive opam-related support in the IRC #frama-c channel on freenode.net (interactive support is often more efficient for installation issues related to opam, especially since it's hard to know in advance which information might be useful).
Dealing with "Invalid user input" errors in the GUI
As a general rule, when trying to open a file in the GUI fails, I'd recommend running the command-line version of Frama-C with the filename. Its output is much more detailed and can indicate if there are parsing issues with the file (which could be due to missing dependencies, non-C99 syntax, or configuration problems).
Otherwise, the Console tab in the GUI should contain detailed error messages, which you could then add to this SO question, in case they are relevant to understand your issue.
Issues with graphical libraries in non-major Linux distributions
The second issue I can see in your question, is the error related to -lgtksourceview-2.0. This means that one of the library dependencies for the graphical interface is missing. Maybe there's a way to fix it, but at the very least it should be possible to identify the error before compilation, and report the incompatibility earlier. The fact that depext did not work is unusual; maybe it's not currently well-supported for Manjaro, but it's worth investigating. Unfortunately, opam can sometimes be complex to handle for first-time users, so I understand it's a bit frustrating and may take more time than you'd want. But if you intend to use Frama-C or other OCaml packages for some reasonable amount of time, it is worth understanding some of the common errors in opam, since it is very useful for handling dependencies.
Handling issues with OCaml dependencies when compiling manually
Finally, the issue with Yojson is probably due to the version of the package that is installed. In particular, versions before 1.6.0 do not have the type Yojson.Basic.t. Frama-C used to support 1.4.1, but the latest version requires at least 1.6.0. Again, it's not obvious to spot in advance all possible issues with different package versions, but reporting them allows us to include checks to prevent it in the future, or at least to give a more precise error message.
Normally opam handles that part, hence why it's recommended even for manual compilation of Frama-C, since it helps manage its dependencies.
Overall, it seems that some underlying issue with the dependencies in opam depext is preventing the whole chain from working properly. Your report does contain much useful information but not all the details, so I believe the interactive route should allow to quickly converge towards a working installation.
I am using header <atomic> in my library code and trying to link the program against the libatomic.so.
Whenever I try to link all the object files and create my library's SO file, I get error
can not find /usr/lib64/libatomic.so.1.0.0
I have this so file under path /usr/lib/gcc/x86_64-redhat-linux/4.8.5.
as libatomic.so. No version is specified in the name.
I tried to specify the path /usr/lib/gcc/x86_64-redhat-linux/4.8.5 with -L option on gcc command creating shared lib, but still it is asking lib /usr/lib64/libatomic.so.1.0.0 to link against for atomic code.
So how do I against the /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libatomic.so in order to create the library?
Why it is asking for libatomic.so.1.0.0 when I do not specify any version in -latomic command line option in gcc command.
My gcc version is 4.8.5-4 and OS is redhat 7.2
Look at the content of the file /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libatomic.so! You'll probably see it is not an actual library, but just a single line of text which looks like:
INPUT ( /usr/lib64/libatomic.so.1.0.0 )
So when you use "-latomic", this file is picked up (as you wanted!) and then the linker goes on to find /usr/lib64/libatomic.so.1.0.0 - which is missing. To have it, you should probably install the "libatomic" package (yum install libatomic). You can also use "yum whatprovides /usr/lib64/libatomic.so.1.0.0" to automatically find the package which should have provided this file.
I have this strange situation that after updating Qt from 4.8 to 5.3, Qt Creator (v.3.2.1) will not take any keyboard input. The keyboard is working normally in other applications.
I'm on Debian Wheezy (7.7) with XFCE, but installed the Qt5 set of packages from wheezy-backports.
Does anyone have an idea what can be done about this?
Update:
As requested, here's the Terminal output:
libEGL warning: DRI2: failed to authenticate
xkbcommon:ERROR: failed to add default include path auto
Qt: Failed to create XKB context!
Use QT_XKB_CONFIG_ROOT environmental variable to provide an addtional search path,
add ':' as separator to provide several search paths and/or make sure that XKB
configurationdata directory contains recent enough contents, to update please see
http://cgit.freedesktop.org/xkeyboard-config/ .
It is apparently a known bug, some messages and posts talks about this issue on the Internet.
Maybe try this, from https://lists.debian.org/debian-backports/2014/10/msg00061.html
Opening Qt5 applications from backports (or self compiled against backported
Qt5) have some trouble finding XCB data:
$ /usr/lib/x86_64-linux-gnu/qt5/examples/quick/d
ialogs/systemdialogs/systemdialogs
xkbcommon: ERROR: failed to add default include path auto
Qt: Failed to create XKB context!
Use QT_XKB_CONFIG_ROOT environmental variable to provide an additional search
path, add ':' as separator to provide several search paths and/or make sure
that XKB configuration data directory contains recent enough contents, to
update please see http://cgit.freedesktop.org/xkeyboard-config/ .
Applications run fine, but can't get input from the keyboard.
As the warning points out, setting the environment variable fixes it:
export QT_XKB_CONFIG_ROOT=/usr/share/X11/xkb
So, try to run qtcreator with the folowing command:
export QT_XKB_CONFIG_ROOT=/usr/share/X11/xkb && qtcreator
~]$ /usr/local/bin/xca
xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb
Qt: Failed to create XKB context!
Use QT_XKB_CONFIG_ROOT environmental variable to provide an additional search path, add ':' as separator to provide several search paths and/or make sure that XKB configuration data directory contains recent enough contents, to update please see http://cgit.freedesktop.org/xkeyboard-config/ .
sudo apt-get install xkb-data (xkeyboard-config)
has solved my problem (no input from keyboard)
I have been trying to build the freetype2 library in OSX Mavericks for several weeks now, but without success.
The trouble is with using GNU Autotools to create the configure build script.
I have installed automake, autoconf, libtoolize, m4 and perl5 using the macports port command.
When executing aclocal, there is supposed to be a file created in the configure directory that contains Autotools macros: aclocal.m4. However, this file is not being output, and the subsequent glibtoolize and autoconf commands are generating a spurious configure script.
The result is: no aclocal.m4 file, and the usual contents of ./autom4te.cache/traces.* being dumped at the top of the generated configure file (the traces.* files are empty).
e.g.:
m4trace:configure.ac:14: -1- AC_SUBST([SHELL])
m4trace:configure.ac:14: -1- AC_SUBST_TRACE([SHELL])
m4trace:configure.ac:14: -1- m4_pattern_allow([^SHELL$])
Any help would be greatly appreciated.
GNU Autotools does not support execution over a working directory stored on a FAT32 file system. It results in spurious m4trace debug messages being output to the generated configure script.
It is unknown why this is, but may be related to the reliance on the sleep command to check whether a file has changed. FAT32 rounds time stamps to the nearest second, where execution and subsequent modification checks may happen on a sub-second timescale.
This has been raised with the development team, but for now, I move my working directory to my OSX boot partition before executing GNU Autotools.
This is sort of a followup to this thread--unfortunately I didn't make any progress at the time so I thought I would start over. I am consistently getting this in the debugging log (QtCreator 2.3.1, Qt 4.7.3, gdb 7.2):
A syntax error in expression, near 0'.\n"
295^error,msg="A syntax error in expression, near0'."
&"Python scripting is not supported in this copy of GDB.\n"
296^error,msg="Python scripting is not supported in this copy of GDB."
&"Python scripting is not supported in this copy of GDB.\n"
297^error,msg="Python scripting is not supported in this copy of GDB."
&"Python scripting is not supported in this copy of GDB.\n"
298^error,msg="Python scripting is not supported in this copy of GDB."
&"Undefined command: \"bbsetup\". Try \"help\".\n"
299^error,msg="Undefined command: \"bbsetup\". Try \"help\"."
dThe debugging helper library was not found at .
&"source /home/matt/QtSDK-4.7.3/pythongdb/gdb\n"
&"/home/matt/QtSDK-4.7.3/pythongdb/gdb:1: Error in sourced command file:\n"
&"Undefined command: \"\". Try \"help\".\n"
300^error,msg="/home/matt/QtSDK-4.7.3/pythongdb/gdb:1: Error in sourced command file:\nUndefined command: \"\". Try \"help\"."
&"Undefined command: \"bbsetup\". Try \"help\".\n"
301^error,msg="Undefined command: \"bbsetup\". Try \"help\"."
dThe debugging helper library was not found at .
302^done
<303set substitute-path /var/tmp/qt-src /usr/include
The specific problem is that without the debugging helper, I'm unable to see the contents of QStrings and many other data structures during the debugging process, which makes it much more time-consuming. The error messages above are symptomatic, the problem arises when gdb can't find the debugging helper.
Anyway, looking at the discussion referenced in the answer in the above thread, I hunted around for different versions of gdb on my system but each one of them produced the same error (with the path changed appropriately of course), including version 7.3.1 when I downloaded it. I've also located libDebuggingHelper.so, but sticking it in different places hasn't helped either. Lastly looking at ./configure --help for gdb, I didn't see any options for enabling/disabling python in the build. Anybody know how I can get this to work?
This site claims you need to configure GDB using
./configure --with-python
It's pretty clear from the error message that the GDB you built does not have python support compiled in.
In gdb/config.log look for messages like checking whether to use python and see why GDB decided to not use Python on your system.
Perhaps you need to install Python development packages?
Once you've configured GDB to use Python, an easy way to check whether Python support is properly compiled in is:
(gdb) python print "hello"
If that prints anything other than hello, you are still not where you want to be.
I solved the problem with
sudo apt-get install gdb-multiarch
Thanks to #Employed-Russian for allowing me to check if GDB indeed has python support.
I did have to use the syntax
(gdb) python print("Hello")
To get a proper response from python within GDB.