I'm running MacOS Big Sur and trying to install valgrind for an assignment.
brew install valgrind doesn't currently work and installing from the tar.bz2 distribution doesn't either.
Running ./configure (according to the readme instructions) returns this at the end:
checking for a supported OS... ok (darwin20.1.0)
checking for the kernel version... unsupported (20.1.0)
configure: error: Valgrind works on Darwin 10.x, 11.x, 12.x, 13.x, 14.x, 15.x, 16.x and 17.x (Mac OS X 10.6/7/8/9/10/11 and macOS 10.12/13)
Judging from that, looks like valgrind hasn't worked for the last couple of MacOS releases.
Is there an alternative for current MacOS releases or is this a good time for me to make a partition on my hard drive for Linux? Or am I missing something with installation?
As mentioned in the comments, Louis Brunner's github repo is your best bet at the moment. This should give you at least a minimally functional build.
Other than the usual version number changes, one of the big, breaking, changes in Big Sur is the fact that the system libraries are cached (and hidden) by dyld. So right now Valgrind is not able to read libsystem_malloc.dylib in order to determine the address of functions like malloc so that they can be redirected.
If anyone wants to take a stab at it, then my guess is that you will need to follow these instructions, and change initimg-darwin.c so that dyld_cache_value is "avoid".
For anyone else looking for an answer, you could use valgrind-macos, a fork of Valgrind on macOS, as recommended by PhillipMills. XCode also provides tools for leak checking.
However, if you don’t use XCode and don’t like the first option, you could try Address/Leak Sanitizer. The difference is that you’ll have to compile and link with one of the sanitizers, but that only requires an extra flag, i.e., -fsanitize=address. Note that Apple Clang doesn’t support leak checking, so you’ll have to grab llvm off Brew. Also, you need to prepend ASAN_OPTIONS=detect_leaks=1 before your executable.
Related
I would want to run sed 's/#line/\/\/#line/' on some particular docs in order to automate this solution to http://stackoverflow.com/questions/16512580/.
I would want that command to be ran by GNU Make automatically only when invoked from Xcode.
Can't just simply use uname -s detection of Darwin because a Homebrew only toolchain is to be maintained in parallel to the Xcode project configuration docs. It has to specifically detect Xcode somehow.
My Xcode right now is reported as Version 9.0 (9A235).
Got ideas?
It seems that you want to get rid of the #line generated by Bison. Then, pass it --no-lines (aka -l) or put %no-lines in the grammar file.
Strictly concerning the question of how to detect XCode in make, it seems that the answer would be to add a flag to the command-line (e.g., make XCODE=1) or to the environment. I don't think there is an automatic XCode-specific flag set to distinguish it from a Mac that is using otherwise the same tools.
For the specific case of getting rid of #line generated by Bison, it seems that this answer may be better. Or if neither of these is doable, I would seek to detect the undesired situation (e.g., with grep or awk) first rather than unconditionally running sed.
I should preface this by stating I'm working with Xcode on macOS Sierra 10.12.6.
I installed GDB with homebrew and it appeared to install fine until I tried to use it. In terminal it kept saying that it was not a valid command. (I'm new to C and was working with my professor. Even he was baffled when I tried to use it after downloading it in front of him). So later I tried to install it by creating the make file and still having problems. I then used homebrew again but to uninstall and reinstall, still having problems.
Now I'm at the point where I can't even run my C files when I use gcc to compile them. I simply get a statement that unable to open file. I've read someone suggest to sudo mv /usr/local /usr/_local and I'm notified that I don't have permission, even after entering in my password.
I've gotten every error when I try to remove all items belonging to gdb. I've gone as far as removing Xcode in hopes that I can do a fresh install of it all.
I'm at the point where I've begun looking into removing my macports entirely.
I'm looking for any advice into how I can try to start off from a clean slate. I need to use gdb on a project that is due and can't get this up and running. Please help talk me from a ledge!
EDIT:
I have used Sublime to create a simple Hello World file and it compiles and runs fine with gcc. So my project file has become corrupted somehow. At least I can calm down a bit. But I would still like to get this gdb issue figured out and install a fresh copy with everything old removed.
I'm working with Xcode on macOS Sierra 10.12.6
I need to use gdb on a project that is due and can't get this up and running
I don't know how to reinstall gdb on macOS, but be aware that gdb is broken on macOS Sierra as of now (at least debugging dynamic libraries), see Bug report.
So if you even get gdb correctly installed you can probably end up with nothing (gdb won't be able to debug what you want).
Try making your file executable using gcc -Wall -g $fileName.c -o $fileName. This will show all the errors that might exists. Secondly, if it doesn't work and you absolutely need to use gdb, using a VM of Linux(recommend Ubuntu if you're new to Linux or Mate) is a good alternative. You then have to just use sudo apt-get install gdb and even install gdb-dashboard git-hub gdb-dashboard if you want to do some serious debugging. That's the quickest fix that I can think of you are in a hurry. Btw good VMs are VirtualBox and Parallel Desktop(if you want to have access to your local files from the VM).
The following html link contains all the relevant bash command line records of the installation process. Thank you for help!
That was a bad question
I didn't use XCode through I know Xcode will make it easier! I use an Air, memory of 4GB currently.
If this won't work easily I probably will quit learning C or run and compile C on Windows. :(
And XCode stuff, whatever.
You command-line output indicates rather clearly that you aren't telling gcc what to compile, so it's throwing its hands up in exasperation:
$ gcc
i686-apple-darwin10-gcc-4.2.1: no input files
You'll need to specify the file you're compiling. Better yet, use an IDE, like Xcode.
<Shrug> What do you want us to say?
Obviousy Macports is trying to build/install gcc but it can't without a compiler. Yes gcc can be built without a preexisting compiler, but good luck and why? Especially when XCode is a free download, click click let it start and a little while later it's done. At that point as pointed out elsewhere, gcc, g++ will work, but it's not actually gcc but clang in disguise.
If you want, you can use macports or brew or whatever later if you really want to, but again why? For programs that only work using gcc extensions? Doubt it. You just want a c/c++ compiler. If you ever want to do programs for the Mac or IPhone, you need XCode anyway, gcc won't do.
I am trying to get memcached running on Windows. I have downloaded memcached stable latest and compiled it using Mingw under Windows 7. Configure failed with error,
checking for libevent directory... configure: error: libevent is
required. You can get it from http://www.monkey.org/~provos/libevent/
If it's already installed, specify its path using --with-libevent=/dir/
Then I downloaded libevent and compiled it. This produced 3 DLLs, libeventcore, libevent-extra and libevent-2.0.5.
I ran configure on memcached again with the option --with-libevent. But for some reason, it fails again with the same error. I have no clue on why it is failing. Can anyone help me to resolve this issue? Or is there a better way to get memcached running on Windows? I have seen lot of pre-built binaries for Windows. But all of them uses old versions of memcached. And AFAIK, Windows is officially supported by memcached in the newer versions.
I am using Windows7 64bit version with MinGW.
After you run make in libevent dir you get the files ready, but to make full use of it, they must be installed. So make install step is needed. If you configured it with a prefix, it will land in the directory of your choice. Otherwise it is /usr/local.
So maybe it's enough to run make install in libevent dir and run configure from memcache without parameters.
If you still have problems passing the configure stage, look at config.log. It shows the source file and the gcc command on which it failed.
Unfortunately successful configure is not everything. Later it fails on inclusion of sys/socket.h, netinet/in.h and netdb.h and perhaps also -pthread gcc parameter. I'm afraid it won't compile on mingw. At least not without a serious porting effort.
As I know, Never had an official Memcached port for Windows (Yes, there were few individual efforts. Last knowing porting effort can find on version 1.2.6 here) Best known Implementation for Memcached for windows on Couchbase with Memcached Bucket.
Late to the party I realize but the answer is to use:
$ export LIBS=-lws2_32
which will place $LIBS at the end of compile calls so that it is linked to libws2_32.a or winsocks2, but this probably means that your did not configure your build correctly and you will subsequent errors such as #include <sys/socket.h> header not found, etc.
see mingw-linker-error-winsock
I am compiling a program through clang+llvm (version 3.1) and trying to run it on a computer which also has the same clang+llvm version. I'm compiling on Ubuntu 10, but the other computer where I'm trying to run has CentOS 5. There (in CentOS), I also encounter problems compiling through LLVM (a compiler pass is implemented in LLVM). That is why I thought about compiling on Ubuntu, take the exe from there and just run it on the CentOS machine.
However, when I try to do that, I get the following error.
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./main)
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./main)
How can I solve this. Please note that I do not have root accesses on that machine.
One solution would be to copy the library from your working Ubuntu machine to your CentOS machine. Put in your Home/Workdir/whereever(TM) and set your LD_PRELOAD variable to that library. But that can be quite tedious as it is possible that this is not the only library that is missing (and maybe libraries depend on other libraries, that you also need...).
This also only works, if both machines have the same architecture (e.g. it wont work if your ubuntu machine is 32 bit and your CentOS 64).
Centos 5 uses an older version of libstdc++ than Ubuntu 11.04 or 11.10, so can't use binaries from there.
Either compile on Centos 5, or find a older compile environment that does work. If you were using gcc, you could also investigate the LSB compiler environment.
Cross compilation is always a difficult issue. In your case you have different c++ library versions on the two machines. In case you do not need to do this often, I suggest you try and solve your compilation issue on CentOS. It's probably the easier way round.