Recently, in an attempt to try xmonad (which apparently requires X11 version >= 1.4.6.1), I tried upgrading Snow Leopard's native X11 via Macports. However, after upgrading, X11 has been acting strangely. For example, it won't automatically start quartz-wm (though it lets me do so manually via xterm). It also crashes after being inactive for long periods of time. Checking the console, I get the following errors: [org.macports.startx: No protocol specified]. Further, despite upgrading to X11 v1.9.2, xmonad still doesn't work, giving me the following error:
Configuring xmonad-0.9...
Setup.lhs: At least the following dependencies are missing:
X11 >=1.4.6.1 (!)
At this point, I decided to just give up on xmonad and use the native X11, but this is now giving me the exact same errors. In particular, the native X is telling me that it can't communicate with the display (:0.0) set in the DISPLAY variable (which apparently has been changed by macports' X11 install). Needless to say, this is very frustrating, and any help would be greatly appreciated. Thanks!
MacPorts does not upgrade Snow Leopards's X11, it installs a completely separate version of the X11 client libraries and whatever other packages you ask it to. This is a deliberate design decision with MacPorts and all its packages. By default and in general, MacPorts installs everything under /opt/local. To not use the MacPorts version, just make sure you do not include any /opt/local directories - particularly /opt/local/bin - in your shell environment variables - in particular PATH - or in any absolute paths to executables and libraries. If you want to totally remove MacPorts, the following will get rid of just about everything:
$ sudo rm -rf /opt/local
The X11 to which the Xmonad error message refers is the Haskell package http://hackage.haskell.org/package/X11/, which doesn't appear to require any particular numerical version of X11 proper or of the X server. In other words, you were barking up the wrong tree.
Related
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 am trying to use a toolbox which makes use of the Matlab's eigs() function. When I run this in Octave (3.6.4, installed via Homebrew on Mac OS X), the following is returned:
error: eigs: not available in this version of Octave
I have found a lot op potential solutions, about getting the ARPACK(-ng) program to work with Octave. I have tried more methods then I can remember, but none seemed to work.
Does anybody know the current status of Octave using the eigs() function? Is this possible, preferably by using packages in Homebrew?
Thanks.
I think you're referring to the fact that as of 3.6, Octave no longer comes with eigs, and depends on an external arpack library. From the Octave release notes:
Summary of important user-visible changes for version 3.6:
---------------------------------------------------------
...
** The ARPACK library is no longer distributed with Octave.
If you need the eigs or svds functions you must provide an
external ARPACK through a package manager or by compiling it
yourself. If a pre-compiled package does not exist for your system,
you can find the current ARPACK sources at
http://forge.scilab.org/index.php/p/arpack-ng
So you'll need an arpack library installed before installing Octave, somewhere visible to Octave. For homebrew, that means under /usr/local/.
Octave's configure file has arpack detection logic, and looks like it will detect arpack during the build process by default, and build against it if present. So Homebrew's octave should pick it up if you have it installed, even without special support for it in the formula.
There's no arpack formula in the current homebrew-science version, but there is an open pull request to add one: https://github.com/Homebrew/homebrew-science/pull/112. Go over there and comment to show support and maybe it'll get merged in soon. Once that's in, do brew install libarpack; brew install octave and your Octave may well pick up eigs. If it doesn't, then put in an issue against homebrew-science to add arpack support.
So, we all know that Mountain Lion doesn't ship with X11 anymore and users needing X11 are directed to download Xquartz. Xquartz installs to /opt, but it also symlinks X11 and X11R6 to /usr. But when building software that requires linking to X11 include files, I've discovered that I must pass an environment variable adding /usr/X11/include (or /opt/X11/include) to the library search path to get ./configure to find the X11 libraries. My question is why?
I've done some research on Google (many results pointing back to Stack Overflow), and I've read Apple's documentation, and these sources all indicate that there is no equivalent in OS X to the /etc/ld.so.conf file found in many (if not all) Linux distributions. Apple even states that DYLD_LIBRARY_PATH is empty by default. However, under Lion (with Apple's last 'official' X11 installed), the same ./configure scripts would find the X11 libraries without adding anything to the library search path.
So, why can't ./configure scripts find X11 libraries in Mountain Lion without explicit modification of the library search path?
Asked more than a year ago... but as I came here with a similar problem...
Note that in the mentioned ruby question, there was no library search path being modified.
That solution just set an environment variable that is picked up by many Makefiles as the flags for the C++ compiler. That example defined the build time -I ncludepath, i.e. where to search for .h eaders -- not libraries (which would have been a -L option to your compiler/linker). Both would have been build time options.
Whether LD_LIBRARY_PATH or DYLD_LIBRARY_PATH -- both are environment variables that are considered by the dynamic linker at runtime. (For more, see http://en.wikipedia.org/wiki/Dynamic_linker )
I have no pre-10.8 machine at hand, but guess that there might have been a symlink
/usr/include/X11 -> /opt/X11/include/X11 -- otherwise I have no Idea atm how
it could have worked before, assuming same sources...
This is another potential solution for such problems (just fixed my realvnc build):
$ autoconf
$ ./configure
So your question for "why?" could be eventually answered with: Because your sources contained a 'pre-built' configure script that was based on older autotools that did not include
/opt/X11/include as a potential location to search for X11 includes or simply did not get some of the above mentioned compile time flags right on your current system.
I have autoconf installed through homebrew -- ahh, great stuff, cheers.
hey i am new to the macports thing as i recently switched to the mac. as i was thinking of developing some applications in my mac i wanted all the usual gnu and opensource tools i need. but i had a small confusion. i was installing git with macports and i noticied it installed a lot of packages like Perl that i already have in my machne. so i was thinking won't there be any conflicts and how does one know which version is used. the macports one or the apple one?
MacPorts installs all of its ports into /opt/local (or whatever prefix you configured it with, but it's /opt/local by default). It installs its own copies of Perl, Python, etc., so that the MacPorts install is standardized, and to avoid conflicts (Apple-supplied versions of some programs like Perl and Python, and some libraries, often lag far behind the latest versions of those tools).
When you install MacPorts, it automatically prepends /opt/local/bin to your $PATH variable (you can change this by editing your shell configuration file), so if you call perl, etc., you'll get the MacPorts version. However, the Apple-supplied versions will still be intact and unchanged, and other programs that rely on those versions will not be affected, either.
There shouldn't be any conflicts, since MacPorts installs all of its programs under a completely separate directory hierarchy in /opt/local/.
If you have multiple versions of software installed (e.g. the default OS X Perl and MacPorts' Perl), then it depends on the order of directories in your $PATH environment variable. MacPorts typically sets itself up with its bin directories earlier in your path, so saying perl at the command line will invoke the MacPorts Perl, not the OS X Perl.
MacPorts installs its own dependencies in the /opt/local tree (you can change this default when you build MacPorts) because its packagers then have a known quantity to test against. In some cases there is a system package for a given dependency that will let you use the system-installed version, but that's actually pretty rare. System vs. MacPort versions are chosen according to whichever comes first on the PATH (for executables) or the linker path(s) for dynamic libraries. Use your standard development tools' options to select the appropriate libraries to link against and you should be fine.
I'm sure this is a newbie question, but every time I've compiled/dl'ed a new version of vim for os x, running vim on the command-line opens up the gvim app. I just want to upgrade the console version (so I can, for example, have python compiled in to use omnicomplete).
If I understsood the question correcty, here is another solution: check out http://www.andrewvos.com/2011/07/23/upgrading-vim-on-os-x-with-homebrew/
Really simple, fast, painless. It uses homebrew-alt and you also need to have mercurial installed (it will prompt you if not).
You can also use MacPorts to handle the installation for you. Once you've installed it, run the /opt/local/bin/vim binary. I place this in my PATH before the system binary dirs (although be aware that this may cause problems for cmdline tools that rely on the versions of tools shipped with OS X).
This may sound stupid, but are you copying the vim binary to /usr/bin? by default, the "vim" path is /usr/bin/vim. If you compile from source, you'll likely need to either copy the vim binary to /usr/bin/vim (thus overwriting the original vim), or launch the compiled version via absolute path (eg. ~/vim-checkout/build/vim).
that's just a guess, however. I can't see it being anything more than that.
With Homebrew:
brew install macvim
ln -s /usr/local/bin/mvim /usr/local/bin/vim
Can also symlink your new binary to /usr/local/bin/