I was working on an OS X system which kept getting annoying pop-ups about the system needing clean up, anti-virus software etc. I was able to see that the window was titled ‘helperamc’.

It turns out this was a remnant from Advanced Mac Cleaner, the use of which I won’t comment on here. The user of the system had tried to remove it when upgrading OS X version, but the annoying advertising component remained.

Killing the process and deleting the application doesn’t work, as it has a daemon to relaunch itself. After some investigation I found the following commands (issued in will sort out this issue and remove helperamc for good:

launchctl unload ~/Library/LaunchAgents/com.pcv.hlpramcn.plist
rm ~/Library/Application\ Support/amc/

As they are user files admin access is not needed. You may need to kill the helperamc process between these commands.


I recently upgraded from OS X 10.10 to 10.11. This has upgraded the version of the gfortran dynamic library from 2 to 3 (in /Library/Frameworks/R.framework/Resources/lib), which in turn causes problems in various R packages (msm, ape).

For those which give an error along the lines of

unable to load shared object

the solution seems to be to use install.packages recursively. Use it on the package that failed. If a dependency fails, use it on that too. Then restart R.

Some packages requiring compilation which link libgfortran (-lgfortran) fail, as the linker line does not give the correct directory through -L. I also have gfortran installed as part of gcc through homebrew, at /Users/john/homebrew/lib/gcc/4.9 (to do this, use ‘brew install gcc’).

Using this, add the line


to the file ~/.R/Makevars. This should work, as long as when you load the library you have this directory either indexed through OS X’s equivalent of ldconfig (if there is one?), or it is in LD_LIBRARY_PATH.


I was trying to compile some C++ of the form

std::vector<std::thread> threads;
for (int i = 0; i<num_threads; ++i)
   threads.push_back(std::thread(logisticTest, kmer_lines[i], samples);

with function prototype

void logisticTest(Kmer& k, const std::vector<Sample>& samples);

on OS X 10.10 with clang++ – Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)

First error message: no matching function for call to ‘__invoke’
Solution: add ‘-std=c++11 -stdlib=libc++’ to CXXFLAGS in Makefile
(thanks to

Second error message: attempt to use a deleted function __invoke(_VSTD::move(_VSTD::get<0>(__t)), _VSTD::mov…
Solution: pass to thread by value rather than reference. e.g.

std::reference_wrapper: threads.push_back(std::thread(logisticTest, std::ref(kmer_lines[i]), std::cref(samples)));

(thanks to

After upgrading from OS X 10.8 (Mountain Lion) to 10.10 (Yosemite), I found that gvim no longer worked and exited with a cryptic dyld message similar to ‘dyld: Symbol not found:’.

The first thing I tried was uninstalling it with homebrew, then reinstalling:

brew uninstall macvim
brew install macvim

But I got a ‘Trace/BPT trap: 5’ during make. Trying to fix this by doing the things suggested by ‘brew doctor’ and installing openssl gave me essentially the same errors.

brew install openssl

/bin/sh: line 1: 71319 Trace/BPT trap: 5 /usr/bin/perl tools/c_rehash certs/demo
make[2]: *** [rehash.time] Error 133
make[1]: *** [openssl] Error 2
make: *** [build_apps] Error 1

However here I could see perl was used in the ./configure step. Trying to run my perl scripts, I found they no longer worked:

dyld: lazy symbol binding failed: Symbol not found: _Perl_Istack_sp_ptr
Referenced from: /Users/jl11/perl/lib/perl5/darwin-thread-multi-2level/auto/Cwd/Cwd.bundle
Expected in: flat namespace

dyld: Symbol not found: _Perl_Istack_sp_ptr
Referenced from: /Users/jl11/perl/lib/perl5/darwin-thread-multi-2level/auto/Cwd/Cwd.bundle
Expected in: flat namespace

My perl install appears to be broken, and that was what was causing all the problems. Something similar was encountered before:

I used perlbrew to fix the problem, and now it all works again! Run the following commands

\curl -L | bash
perlbrew install stable ­-Dusethreads
perlbrew switch stable

I had a PERL5LIB environment variable set which caused problems, check your @INC:

perl -e 'print join "\n", @INC'

If it’s set put ‘PERL5LIB=’ in your ~/.bashrc or equivalent

Finally, you may need to install your perl modules into the new perl version again, documented here. Also, be wary of using scripts which have #!/usr/bin/perl as their first line, as they will run using the wrong perl version. perl <script_name> is safer