Installing MacPorts on OS X 10.11 ‘El Capitan’

High Sierra Update:  If you are looking for instructions on how to manually install MacPorts onto the High Sierra GM release, check here:  Installing MacPorts on MacOS “High Sierra”

Update: MacPorts has released their official El Capitan installer. You should probably use it instead. 🙂

Update: Since people are ignoring my above comment, I have updated the below instructions to reflect the version changes reported by Chrisp in the comments.

Another year, another OS X update.  If you are like me, you’ve weaseled a copy of the OS X 10.11 ‘El Capitan’ Gold Master installer, and you have started checking to see how much of your software is going to break if and when you install.  Given the issues I’ve had in the past, MacPorts is the very first thing I test.  🙂

The first thing I noticed is that there is no El Capitan installer for MacPorts, and the Yosemite installer will not run on OS X 10.11.  So, we are back to compiling it ourselves.  Fortunately, this goes pretty smoothly.

The first caveat is that in addition to needing access to OS X 10.11 ‘El Capitan’ , you will need a copy of Xcode 7 (beta, RC, etc).  You won’t be able to compile MacPorts for El Capitan with Xcode 6 because of changes to one or more of the header files that ship with the OS X 10.11.

The second caveat is that I did a clean install of OS X 10.11 ‘El Capitan’, so my instructions may not adequately deal with any cruft left over by previous installs.  If you have an upgrade issue, please comment here and I’ll do my best to help you out and improve the instructions.  You may want to follow the MacPorts uninstall instructions before starting the below steps.

  1. Install OS X 10.11 ‘El Capitan’
  2. Install Xcode 7
  3. Launch Xcode:
    1. Agree to the license.
    2. Let it install the extra components it says it needs.
    3. Quit xcode.
  4. Open a terminal window:
    1. sudo bash
    2. export PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
    3. xcode-select --install
    4. cd Desktop
    5. mkdir macports
    6. cd macports
    7. curl -O https://distfiles.macports.org/MacPorts/MacPorts-2.3.4.tar.gz
    8. tar xzvf MacPorts-2.3.4.tar.gz
    9. cd MacPorts-2.3.4
    10. ./configure --enable-readline
    11. make && make install
    12. echo 'export PATH=/opt/local/bin:/opt/local/sbin:$PATH' >> ~/.profile
    13. source ~/.profile
    14. port -v selfupdate

At this point, you should be ready to start reinstalling your ports!  Wee!

If you see this error at step 4-10:

checking for Apple Foundation library... no
configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your environment, preventing the use of GNUstep's Foundation library
configure: error: Could not find a working Foundation implementation

It means you either have not installed Xcode 7 GM, or that you are running Xcode 7 Beta.  Xcode 6 doesn’t know how to handle the changes to /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h that happened with El Capitan.  The configure script is able to find the header file, but the test compile fails so it reports that the Apple Foundation library isn’t there.

If you are running Xcode Beta, you can get around this by using the following command in the shell you opened above, and then going back to step 4-10:  (Thank you SadDigger for the comment on Reddit!)

xcode-select -s /Applications/Xcode-beta.app

Update 2015-09-15 11:06AM – Fixed a typo in instruction 4-3 where WordPress was converting a double-hyphen into an extended hyphen.  I have also updated it to the latest version of MacPorts, so that the final just updates the ports rather than rebuilding the whole thing. Sorry about that!

The Cheap Parts Paradox

Every hobbyist has experienced it, and yet it seems to be the hardest lesson to retain over time: The more money you save by going with cheap parts, the more of your time you will waste getting them to work… if you can.

I was recently reminded of this rule while adding GPS to a Raspberry Pi project on which I was working. One of my co-workers had recently had good results with a GlobalSat USB dongle on a Pi project, and even though I had an Adafruit Ultimate GPS Breakout in my wishlist I was enticed by the price and the plug-n-play state that didn’t require me to do any additional wiring. So, I ordered a GlobalSat BU-353-S4 from Amazon.

Getting gpsd set up was pretty trivial, but the results I was getting from ‘cgps -s’ was inconsistent.   Despite the GPS unit reporting that it had a lock, the clock display was several hours off from the displayed timezone, and the ‘Speed Err’ was +/- 300MPH.  The unit, which was marketed as having a start time of less than 15 seconds, needed to run for an hour or more to finally settle down.  Meanwhile, ‘cgps -s’ would keep crashing after a few minutes at most.

At the time, since this was my first experience with gpsd, I assumed cgps was just unstable.  After a bit of googling, and reading other people’s tutorials, it became clear that cgps wasn’t unstable and that something was frak’d with my rig.  That’s when I visited the gpsd hardware compatibility table.  On the entire table, the only device with a ‘do not buy’ rating is the BU-353-S4.  (Turns out my co-worker has bought the GlobalSat BU-353, which doesn’t have the ‘do not buy’ rating’)

I’ve since wired up an Adafruit Ultimate GPS Breakout directly to my Pi project.  It just works.   GPS lock was quick, time reported was correct, margin for error was reasonable, and I was able to run ‘cgps -s’ for hours without issue.

It’s easy to be tempted by the plethora of cheap parts on Amazon and eBay.  Not to mention that sweet perk of free shipping…  But sometimes it just isn’t worth it.  There is a huge value in buying parts that have been fully vetted by someone with more expertise, even if it does mean you have to solder eight measly wires.

Raspberry Pi, and Breaking the Arduino Mindset

I build a lot of projects around Arduino micro-controller boards.  They are simple, easy to program, have lots of fiddly I/O ports, and there are all kinds of crazy ‘shields’ for extending their functionality.   I have published a couple of Instructables that utilize Arduino controllers, and I have several projects that I still need to document.

I had one of those D’oh! moments today, when I realized that I had become stuck in an Arduino mindset, and it was holding me back.

I’m building a set of Raspberry Pi image capture systems for my Jeep.  Each Pi will be running a camera.  One will be shooting GPS tagged stills, and the other will be recording video in five minute segments.  I need two Pi’s because the cameras I am using have a single dedicated port on each Pi.   Maybe the camera port dependency is what got me locked into mirrored system mindset, or maybe I’ve just spent too much time fiddling with Arduino projects.  Either way, I ordered a pair of Ultimate GPS modules from Adafruit.

It wasn’t until after the order had already shipped that I realized this was a bit of waste.  I don’t need multiple GPS units, I just need to network the Pi systems to access a single instance of GPSD.  I’ve got a sweet ASUS WL-330N that I can use to build a low power-draw wifi network in the Jeep, and two USB 802.11n modules cost less than a single Ultimate GPS module.  I plan on giving the Edimax EW-7811Un modules a try.  There’s a decent write-up on making these work, so I hope I won’t get burned by the Cheap Parts Paradox.  (I’m only giving these a shot because Adafruit is out of stock on their RTl8192cu based wifi modules.)

How many other Ardunio-isms can I break during this project…

I use Amazon affiliate links in some of my posts. I think it is fair to say my writing is not influenced by the $0.40 I earned in 2022.