Building LLVM’s shared library on Mac OS X 10.6

January 15th, 2011 § 0 comments § permalink

I’ve been working a little bit on the ruby-llvm project (Ruby bindings for LLVM using Ruby-FFI)–mainly adding tests to the already existing functionality–and so had to build LLVM as a shared library.

Building LLV as a shared library on most platforms is trivial. It’s just a matter of enabling a flag on the configure phase of the build.

./configure --enabled-shared

I actually use brew to build it, but the principle is the same:

brew install llvm --shared

However, just building it like this on Mac OS X 10.6 results in the following errors when loading the library on Ruby-FFI:

dyld: loaded: /Users/<user>/llvm/2.8/lib/libLLVM-2.8.dylib
dyld: lazy symbol binding failed: Symbol not found: 
  Referenced from: /Users/<user>/llvm/2.8/lib/libLLVM-2.8.dylib
  Expected in: flat namespace

dyld: Symbol not found: __ZN4llvm2cl6Option11addArgumentEv
  Referenced from: /Users/<user>/llvm/2.8/lib/libLLVM-2.8.dylib
  Expected in: flat namespace

Trace/BPT trap

After some investigation and an e-mail exchange with Takanori Ishikawa, I arrived at the following patch which solves the problem and allows LLVM to load cleanly as a shared library:

diff --git a/Makefile.rules b/Makefile.rules
index 9cff105..44d5b2d 100644
--- a/Makefile.rules
+++ b/Makefile.rules
@@ -497,7 +497,7 @@ ifeq ($(HOST_OS),Darwin)
   # Get "4" out of 10.4 for later pieces in the makefile.
   DARWIN_MAJVERS := $(shell echo $(DARWIN_VERSION)| sed -E

-  SharedLinkOptions=-Wl,-flat_namespace -Wl,-undefined,suppress \
+  SharedLinkOptions=-Wl,-undefined,dynamic_lookup \
   ifneq ($(ARCH),ARM)
     SharedLinkOptions += -mmacosx-version-min=$(DARWIN_VERSION)

The options above use the default two-level namespace on OS X and change name resolution to run-time resolution.

Using those options doesn’t seem to have any ill effects but I’m curious why LLVM doesn’t do that already, especially considering many other dynamic libraries for Mac OS X are compiled using the new options specified above. In fact, the former options actually seem to be remnants from pre-10.3 days. Just in case, I’ve asked that very question on the LLVM-dev mailing list.

Meanwhile, the patch works for me. I also made available a modified version for brew. YMMV.

On jedis, ninjas, and samurais

January 8th, 2011 § 7 comments § permalink

Geeks of all stripes often like to refers themselves as being the Computer Science equivalents of some warrior society or other that, let’s be honest, have the tons of cool in their day-to-day affairs, imagined or not, that real people don’t. I can’t really fault anyone who does that because I’ve done it as well.

Granted, I never liked Star Wars that much. Being a Star Trek fan, I always considered Star Wars something you grew up from after a while–good for kids but not much else (please, don’t kill me, I’m just kidding–well, not that much). Star Wars is fantasy, Star Trek is science. But, yes, the Jedi are cool. I’d rather yield a light-saber than a phaser, but give me a quantum torpedo any day over any weapon the Empire or the Republic can devise.

And there are also the samurai–that old-school, valiant, often involved in hopeless, honor-bound matches. From Seven Samurai to The Last Samurai–and let’s not forget Eiji Yoshikawa‘s novel–we Westerns have always admired the way those mostly Japanese warriors conducted themselves, considering their Way of the Warrior something at least to aspire to.

Finally, there are always the ninja or shinobi. Sure, their are not very popular nowadays, but there was a time they were the rage of the young population. As with the samurai, theirs was an art grounded in pretty much the same principles of honor and duty–although they were the functional equivalent at their height to a Black Ops team while the samurai could be considered more of Special Forces, sometimes for hire (as ronin) and sometimes bound to a given House.

But one thing all those orders have in common is that they were mostly monastic-like orders, based on an strict code as how to proceed, on a very strict training discipline, and, in many cases, honor-bound not to contract any format relationships beyond those formed with their brothers in arms.

As geeks, we often like to compare ourselves to members of those orders because, as I said, they are cool. Except for Ninjutsu, which preserves many of the training shinobi, you can’t really become one of them but you can aspire to some of the same ideals, try to live by the same codes because as much of them apply to interpersonal relationships as to war and survival itself.

But there’s something we mostly forget about those orders–the fact that they were primarily and above it all, about discipline. Both the real, historical training of the samurai and ninja and the imagined Jedi education required an immense and live-long commitment to discipline that overshadowed anything else the person would do. And, most of the times, required sacrifices.

Which brings me to my point.

In the past four years, I’ve been part of almost ten different teams. I’ve seen teams succeed and fail, to recover and proceed, to bond and become great, to be disbanded and go on with their lives. In short, I’ve been part of a large number of situations in which to participate and observe how teams interact and get things done.

And in all those years, one of most important thing that separated bad and even good teams from great ones was discipline, often the most overlooked part in the examples geeks try to emulate when choosing their heroes.

It’s quite ironic that people often profess to like Agile methodologies because they seemingly create order from chaos through self-managed teams, teams that supposedly don’t need much direction to get going and do great things, teams that don’t need to be told what to do.

But the truth is, Agile will only succeed with teams that are very disciplined and that understand the trade-offs you will need to make in order to make a project happen. Yes, Agile is about embracing change but that only means you will have to make sure you work better with your peers and with the organization as a whole–understanding change, and those trade-offs requires discipline and a down-to-earth approach that most people seem to overlook when becoming enchanted with Scrum and its sister disciplines.

I was talking to a friend a couple days ago and we were discussing how often geeks of the younger generations are using the semi-ADD excuse to go off track on projects and postpone things. Geeks, he was saying, are notorious by their short-attentions spans.

I think–and said that to him–that the opposite is true. The true geeks are those disciplined enough to maintain their focus and keep going in spite of distractions. You need to be pretty focused if you want to debug that heinsenbug that has been plaguing you for the past 40 hours and keeping your server crashing each couple of hours. You need discipline to keep poring over documentation, going back and forth, to find that elusive piece of information that will optimize your routine so that it will really run for large datasets. And you need a strong sense of direction to participate in a team and keep track of everything that’s going on in an ever-changing environment.

In short, discipline is what separates the dilettantes from the craftsmen. It’s what makes thing happen and what really creates great teams. It doesn’t mean you need to be a prick, or that you can’t have fun, or even that you need to follow pre-ordered steps every time you do something. But it means you need to practice and give thought to what you’re doing until it becomes second nature, until you really master your art.

And that’s what ninjas and Jedi and samurai do. They don’t dabble, they don’t run when the going gets weird and the tough turn pro. They just–you know–do it, and do it well.

Where am I?

You are currently viewing the archives for January, 2011 at Reflective Surface.