I am new to valgrind, using a windows system. But this pop up when I try to use it. What can I do?
Valgrind is not available for Windows. On their home page, it says:
It runs on the following platforms: X86/Linux, AMD64/Linux, ARM/Linux, ARM64/Linux, PPC32/Linux, PPC64/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, X86/Solaris, AMD64/Solaris, ARM/Android (2.3.x and later), ARM64/Android, X86/Android (4.0 and later), MIPS32/Android, X86/Darwin and AMD64/Darwin (Mac OS X 10.12).
For alternatives, you can refer to this stackoverflow question. Many people have listed other options.
EDIT:
Since you are using WSL, that does change things. (Next time, it would be good to add that sort of information to your question. Even if Valgrind worked on Windows, using WSL does change the answer.) You should know that valgrind will only work for Linux binaries then. You won't be able to use Visual Studio code.
Otherwise, it should technically be possible, but I've worked with WSL and since it's still in its early stages, things don't always work as you expect. It might just be in your case though, that you need to do the first possible fix by sudo apt install libc6-dbg.
If that doesn't work, here is an answer about how to install it. No guarantees that this works though for you.
Related
I am trying to do heap profiling of C++ application on unix platform. I have tried valgrind's massif but it makes application very slow and affects behavior of the application.
I was searching for other options and came across gperftools and heaptrack. Though these can be viable solution for my problem here. But I have limitation here I don't enough privileges to install these tools.
Is there any way I can setup gperftools or heaptrack without installing them in unix?
Thanks in advance
You can always install things by specifying something like --prefix=$HOME/mygperftools to configure. Then it will install within your home directory.
Long story short, this is what I get when I try to install Qt 5.4:
My system is Windows 8.1 x64 and I have plenty of space on all of my drives. What I've tried so far:
using both offline and online installers
resetting %TMP%/%TEMP% environment variables (I use tmpfs partition for that)
running installer as administrator
Based on the comment discussion, it seems to mean some corruption on your system that may trigger this failure as a reinstall of your Winows 8.1 seems to have made this working.
For future reference: in general, you could debug this issue by trying to install 32 bit verison instead of 64 bit. If that does not work, you could pick up minimal installation. If that does not work, you could try another compiler variant, etc.
Naturally, you always need to make sure that you run this as system administrator, too.
Disclaimer: this fresh issue reported could also be an issue under "extreme" circumstances:
Segfault when running installscript.qs using "replace"
I'm new to this community and this is my first question. I know many people had had this problem before, but, it seems as if people solved it their own ways and I tried all the solutions I could find in google (and here, respectively), but none of them seem to work for me like it was supposed to. And just to make it clear, I use 32-bit Windows XP. Some versions that may work in 64-bit or newer operating systems may not work on mine.
So I'm very new to C and C++, I started by installing the Eclipse CDT, the moment I found out it did not have a compiler was when I installed MinGW which was bundled with a C compiler, a C++ compiler, and the MinGW Developer's Toolkit (which included MinSys). So after that, I started by creating a new empty C++ project called 'HyScript'. And did these:
I set the environment variables as:
C:\Program Files\Java\jre7\bin;E:\Mark\MinGW\msys\1.0\bin;E:\Mark\MinGW\bin
Then, I restarted eclipse, deleted the old projects, and created a new one with the same name (deleted the old folders) and chose the toolchair, "Cross GCC".
Now I haven't even started writing code, but there are already 4 errors:
Here's the link to the dropbox file
The last thing I did was open up the CMD before going here, and this happened: Here's another link to the dropbox file
I don't understand anymore... What did I do wrong? I set the environment variables right, I supposed. And, after doing some research, I still can't find a proper solution for me. It's been two days now, and this error still hasn't gone away.
You chose wrong toolchair "Cross GCC". Please select "MinGW"
The latest version of G++ can be found here. Please do NOT install it in the default directory but use this:
C:\MinGW
If you still have problems, uninstall everything you did, and watch these video instructions.
I have a problem with installing OpenGL (and GLut) and using it with Ocaml.
I have tried many different packages (under both Linux and Windows) and always got problems
about not found modules or other.
What will be easier : Linux or Windows? What should i exactly do? Which package of bindings is the best? ( are bindings is enough or i need to download some other things?)
Could anyone describe it step by step in a way that can be easy to follow?
Here are the exact steps :
sudo aptitude install liblablgl-ocaml-dev
cp /usr/share/doc/liblablgl-ocaml-dev/examples/simple.ml .
ocamlfind ocamlopt -linkpkg -package lablgl.togl simple.ml -o simple
./simple
I don't have the motivation to walk you through the installation process at the moment, but here are some (hopefully helpful) comments:
You generally want to use OCaml in *NIX because OCaml shows a very clear bias toward it. In particular, its debugger and profiler are not available in Windows.
One issue I randomly run into when installing new libraries in Linux (which may be a sign that I'm doing something dumb, come to think of it; oh, well) is permissions errors causing module loading errors. Try tracking down where the relevant libraries were installed and check that they're accessible (e.g. try lsing them as a user; seeing them in a directory is not enough).
For example, I recently installed OCamlMPI but was getting errors about it not being able to find modules even when I gave full paths to them.
It turned out that the directory it was stored in ($(ocamlc -where)/ocamlmpi) had a modmask of 0744 (i.e. drwxr--r--) when it should have had 0755 (i.e. drwxr-xr-x). After the permissions were changed, the modules loaded and worked just fine.
In fact, that's actually a problem I've run into when installing Python modules, too. Maybe I am doing something dumb somewhere.
Anyway, I hope that helps. :)
http://code.google.com/r/hectorchu-go-windows/source/list
If you could compile it successfully, I like to know the procedures of how to.
Assuming you are using Hector's source tree:
Install MinGW and MSYS, along with MSYS Bison and any other tools you think you'll find useful (vim, etc).
Install ed from the GNUWin32 project.
Install Python and Mercurial.
Clone the [hectorchu-go-windows mercurial repository](https://hectorchu-go-windows.googlecode.com/hg/ hectorchu-go-windows) to C:\Go.
Run an MSYS shell (or rxvt). The rest of these are bash commands...
mkdir $HOME/bin
export PATH=$HOME/bin:$PATH
export GOROOT=C:\\Go
export GOARCH=386
export GOOS=mingw
cd /c/Go/src
./all.bash
Correct errors as it spits them out at you, repeat step 10 until it starts building.
It's the same idea as on Linux or MacOS, basically.
However, I still stand by what I said in my comment above: this isn't necessarily going to generate anything that actually works yet. You'd be better served by waiting until this effort has merged into the main Go tree before tackling it, unless your interest is in assisting with the porting effort.
Update: there is now a mostly-functional pre-built windows port available, for those not interested in building the compiler themselves. However, given the rate of change of the project, the lack of formal releases (other than the hg "release" tag), and the possibility of Hector's changes being merged into the main branch soon, keeping up with development via source builds is likely to produce better results over time.
Just FYI, there is seems official one now.
http://code.google.com/p/go-windows/
Hector said he was only able to get as far as being able to compile and run an empty main. See issue 107:
http://code.google.com/p/go/issues/detail?id=107
There is still a lot of work to do in porting that, especially since the code has lots of dependencies on ptrace and syscall, not to mention the different threading models between Linux/BSD and Windows.
Update:
There's a new thread on golang-nuts (started 26.03.2010) with a link to a recent build and some current building instructions (using MinGW+MSYS).