I've got Mac OS X Sierra 10.12.3, I know that Valgrind may not be compatible with my system. I've successfully ran automake and the svn, however when I try to run make, it says:
priv/ir_opt.c:5930:14: error: explicitly assigning value of variable of type 'Int' (aka 'int') to itself [-Werror,-Wself-assign]
for (m = m; m < A_NENV; m++) {
Anyone know if this is due to compatibility with Mac OS or something else? Thanks.
As Jens suggested, I've found ir_opt.c (note for people with the same problem: be wary, as there are several ir_opt.c files, you need to edit the one in VEX/priv/ir_opt.c) and changed the m = m to m = 0, since the variable m was declared as 0 a few lines above.
Valgrind won't work on MacOS X Sierra, I have tried for a while.
I understand you got it to install with SVN, so did I, and I never even ran into this error you're having. But if you actually run valgrind --tool=memcheck --leak-check=full -v ./<program> you will find yourself running into an error.
From what I've read, this is caused by something in the OS X source code that the developers of valgrind aren't able to make modifications to their software for, because the part of OS X causing the error is under license and closed source. Or it was until recently and they haven't gotten to updating their own source code yet, or something like that.
Anyways, if you want to use valgrind on OS X you'll have to install a virtual machine with linux on it. I'm using VirtualBox with lubuntu and I'm sharing my home folder to the VM, and I'm not having any problems running memchecks that way. Any distro should be fine, but IMO the lighter the better.
If for some reason it actually does work for you with valgrind memchecks, then I guess you're just lucky. I'd still suggest you switch to using a linux VM anyways, because there is no guarantee that valgrind will function fully on OS X and it may not catch everything like it's supposed to.
Related
I'm writing a parallel program using Open MPI. I'm running Snow Leopard 10.6.4, and I installed Open MPI through the homebrew package manager.
When I run my program using mpirun -np 8 ./test, every process reports that it has rank 0, and believes the total number of processes to be 1, and 8 lines of process rank: 0, total processes: 1 get spit out to the console.
I know it's not a code issue, since the exact same code will compile and run as expected on some Ubuntu machines in my college's computer lab. I've checked homebrew's bug tracker, and no-one's reported an issue with the Open MPI package. I'm at a loss.
Check which mpirun you are invoking. The mpirun that is being executed is launching 8 independent instances of the binary. So each instance is an MPI application with a universe size of 1 and rank 0.
Also, unless you are planning to run the final code on a cluster of OS X boxes, I highly recommend installing a Linux version in a VM, like virtualbox, to test & develop these codes.
Uninstall previous MPI implementation completely.
In my case I installed MPICH2 first, then uninstalled it, and changed to OpenMPI. Then same case occured, all process' rank were 0. What I did to fix this problem is: uninstall MPICH2 completely from my system (I use Ubuntu/Debian Linux).
# apt-get remove mpich2
# apt-get autoremove
Today I met the same problem like you. And finally I got the solution.
See https://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_All_my_processes_get_rank_0
Simply speaking, the answer says, MPI needs suitable PMI to tell processes about their ranks and something else. Therefore, we need to use corresponding mpirun/mpiexec to run the MPI program.
I guess that your problem is related to the mismatch between mpi program compiler and the mpirun tool. So try to uninstall all, and install MPICH/openMPI(make sure just install one of them).
I have had the same problem with openMPI in C on linux. Using MPIch2 in stead , the problem was fixed (but remember to run MPI_Finalize() at the end or it gets weird.)
I am trying to build Firefox OS 2.2 on Ubuntu 14.04, but I keep running into an error that reads:
configure: error: Only GCC 4.6 or newer supported
*** Fix above errors and then restart with\
"make -f client.mk build"
> Build failed! <
This would normally lead me to suspect I might need GCC 4.6, but I am already using that. I have successfully built 2.0 and 2.1 on this machine in the past, and 1.1-1.4 previously on one of the '13 versions of Ubuntu before that, and I have had export CC=gcc-4.6 and export CXX=g++-4.6 in .profile practically since I installed 14.04 on this machine.
To see if I could spot anything obvious in the output I tee'd it to a file, and it is taking a good 7000 lines of output to reach the point where suddenly it thinks I am using a different gcc. If I change CC and CXX to not specify the version then it complains a lot sooner, so I take that to suggest that it is finding the right version for quite a while before complaining about this?
In any case, I am not finding anything else quite like this, and my experience with building mobile OSes is admittedly limited (only Firefox OS builds) but up until now the instructions have either worked or produced errors I could find someone else posting about already. Hopefully someone else happens to know something about why gcc-4.6 would give an error about needing version 4.6?
Edit
Turns out, there is a Bugzilla Bug Report (1121600) that mentions this. If I get the general sense of what it says, I think there is some kind of configuration thing wrong that is known to be true for some of the models that one can compile Firefox OS for?
I thought I would go ahead and put something about that here, since I ran into that. I wish I had a better sense of what the issue was so I could just fix it for my one device, but in case that is helpful to someone else searching for this who has not come up with the terms that led me there yet, that is apparently what is going on.
https://bugzilla.mozilla.org/show_bug.cgi?id=1121600
try replace:
<project name="platform_build" path="build" remote="gp-b2g" revision="501521623cc9a3117799a040e868bddf26b6cbde">
with:
<project name="platform_build" path="build" remote="gp-b2g" revision="3ce5007ab3562021551a35e2c06d323d1e8ee048">
and comment in config.sh (or will override your change)
repo_sync() {
rm -rf .repo/manifest* &&
to:
repo_sync() {
#rm -rf .repo/manifest* &&
finally execute the config script again
BRANCH=v2.2 ./config.sh <YOUR DEVICE>
I'm in trouble to make flyspell to work in emacs. I'm a Mac user, but I'm not using Aquamacs, which seems to provide this facility by default.
Starting new Ispell process [/usr/local/bin/aspell::default] ...
ispell-init-process: Error: No word lists can be found for the language "en_US".
The error message is trying to tell you that Emacs started the external program aspell in a subprocess, which is good, but that it couldn't find its dictionary file, which is bad.
Try typing M-x ispell-change-dictionary RET SPC to see if there are any dictionary files that Emacs knows about, and select one of them.
If that doesn't work, then there is something wrong with your installation of flyspell. What to try next depends on the version of Emacs you are using (the terminal version that comes with OS X, a newer terminal version installed via Homebrew or MacPorts, the Cocoa version, or Aquamacs). On my machine, for example, I am running Cocoa Emacs 24 under Snow Leopard, and flyspell.el comes preinstalled, but to actually get it to work I had to install the aspell package using Homebrew (which provided the aspell executable and its dictionary files). Can you give us more information about your environment (OS X version, Emacs version, etc.)?
I've found a lot of questions on .inputrc, and the answers included people using Mac OS X terminal.app.
But I've set this property on and it didn't change readline's behaviour. I tried the same .inputrc on Ubuntu and it worked…
Is there some specific action I should take on terminal.app?
Well, I think I've finally cracked it.
I will answer my own question for future reference here:
Mac OS X uses editline (descendant from libedit that kinda emulates readline) instead of the more commom readline command line text handler.
I'm still learning how editline works, but I guess it isn't 100% compatible with readline's .inputrc.
So my completion-prefix-display-length attribute probably doesn't work with my version of OS X editline.
So that was it indeed.
I've made the following test to prove my hypothesis:
I've compiled readline under Mac OS X and then run bash with the readline lib I've compiled (through with-readline tool).
It worked fine, all my inputrc attributes worked and I finished my questions.
So in Mac OS X readline is shadowed by editline (it still has readline.h includes and realine's dynamic libraries, but they are editline's code).
I have a unix command line app (with big nasty makefile) that I'm trying to run on a mac. I am compiling it on a 10.6 system, with all of the appropriate libraries of course. The deployment environment is a 10.5 system, with no extra libraries.
I compiled without -dynamic, and it appears to have static libraries, correctly. When I run it on the 10.6 system, it works. However, when I run it on the 10.5 system, I get:
dyld: unknown required load command 0x80000022
I got this same error when I compiled things for the 10.6 system using the 10.5 xcode, so it looks like a version mis-match type problem. However, I used gcc-4.0, and
$CFLAGS = -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
so it SHOULD be set up for 10.5... any ideas?
thanks
Editing an ancient question:
I have the exact same problem on a different computer. This time I am at 10.5.8, fully update, the same executable works on 10.6 still.
Has anyone had any luck with this in the months since I asked this?
The reason for the dyld 0×80000022 error can be that, you are linking on OS X 10.6, and OS X 10.6 will use a load command (LC_DYLD_INFO_ONLY = 0×80000022) that OS X 10.5 does not understand.
To fix this, make sure you are using a deployment target by setting the environment variable just before your link command:
export MACOSX_DEPLOYMENT_TARGET=10.5
(or setenv MACOSX_DEPLOYMENT_TARGET=10.5)
You can always check if your executable uses the right load command like this:
otool -l executable
It will either show LC_DYLD_INFO_ONLY (without deployment target) commands or LC_DYLD_INFO (with deployment target).
I have been searching for the same issue, as I develop on 10.6 but must have a version that works on 10.5. In addition to the compiler flags above, you should add:
-no_compact_linkedit
It is described here:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/ld.1.html
where it says:
Normally when targeting Mac OS X 10.6, the linker will generate compact information in the __LINKEDIT segment. This option causes the linker to instead produce traditional relocation information.
I got there from a discussion on the xcode-users mailing list about "unknown required load command 0x80000022".
i was able to solve this by passing -mmacosx-version-min=10.5 to the linker, e.g. --extra-ldflags="-mmacosx-version-min=10.5" passed to configure for ffmpeg which i was building shared. more info: http://lists.apple.com/archives/xcode-users/2009/Oct/msg00530.html
Depending on how many libraries you use, it may be difficult to get all of them linked statically. What does "otool -L your_binary' tell you?
In order to get a self-contained package for an application of my own, I made a custom MacPorts install in a non-standard directory, so that I could dynlink with the libraries from that directory and only be constrained in asking people to install the whole thing in the same place on their computers. Not great, not the Mac spirit at all, but it's an Unix app and you need to be familiar with Unix to use it anyway.
Good luck
Pascal
It turns out that there is a dynamic library load function (0x22) that got added at 10.5.6. The system I was running on was 10.5.5. I upgraded to 10.5.8, and everything runs!
Ok, SECOND solution, and NOT very satisfying, is to find a 10.5.8 computer, install the developer packages and re-compile... same for powerPC... sad but it will work...